Access control using impersonization

ABSTRACT

A first service submits a request to a second service on behalf of a customer of a service provider. The request may have been triggered by a request of the customer to the first service. To process the request, the second service evaluates one or more policies to determine whether fulfillment of the request is allowed by policy associated with the customer. The one or more policies may state one or more conditions on one or more services that played a role in submission of the request. If determined that the policy allows fulfillment of the request, the second service fulfills the request.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/237,505, filed Aug. 15, 2016, entitled “ACCESS CONTROL USINGIMPERSONIZATION,” which is a the continuation of U.S. patent applicationSer. No. 14/096,783, filed Dec. 4, 2013, now U.S. Pat. No. 9,420,007,entitled “ACCESS CONTROL USING IMPERSONIZATION,” the disclosures ofwhich are incorporated by reference herein in their entirety.

BACKGROUND

The security of computing resources and associated data is of highimportance in many contexts. As an example, organizations often utilizenetworks of computing devices to provide a robust set of services totheir users. Networks often span multiple geographic boundaries andoften connect with other networks. An organization, for example, maysupport its operations using both internal networks of computingresources and computing resources managed by others. Computers of theorganization, for instance, may communicate with computers of otherorganizations to access and/or provide data while using services ofanother organization. In many instances, organizations configure andoperate remote networks using hardware managed by other organizations,thereby reducing infrastructure costs and achieving other advantages.With such configurations of computing resources, ensuring that access tothe resources and the data they hold is secure can be challenging,especially as the size and complexity of such configurations grow.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1 shows an illustrative example of an environment in which variousembodiments can be practiced;

FIG. 2 shows an illustrative example of an environment in which variousembodiments can be practiced;

FIG. 3 shows an illustrative example of a cryptography service inaccordance with at least one embodiment;

FIG. 4 shows an illustrative example of a service in accordance with atleast one embodiment;

FIG. 5 shows an illustrative example of a policy management service inaccordance with at least one embodiment;

FIG. 6 shows an illustrative example of an environment in which variousembodiments can be practiced;

FIG. 7 shows an illustrative example of an environment in which variousembodiments can be practiced where the figure illustrates how servicesare accessible in accordance with at least one embodiment;

FIG. 8 shows an illustrative example of a process for evaluating arequest in accordance with at least one embodiment;

FIG. 9 shows an illustrative example of a policy document in accordancewith at least one embodiment;

FIG. 10 shows an illustrative example of a policy statement inaccordance with at least one embodiment;

FIG. 11 shows an illustrative example of a process for processing arequest in accordance with at least one embodiment;

FIG. 12 shows an illustrative example of various types of data that maybe stored by a service provider in accordance with at least oneembodiment;

FIG. 13 shows illustrative examples of policies in accordance withvarious embodiments;

FIG. 14 shows an illustrative example of a response from anauthentication service in accordance with at least one embodiment;

FIG. 15 shows an illustrative example of a process for evaluating anauthentication request in accordance with at least one embodiment; and

FIG. 16 illustrates an environment in which various embodiments can beimplemented.

DETAILED DESCRIPTION

In the following description, various embodiments will be described. Forpurposes of explanation, specific configurations and details are setforth in order to provide a thorough understanding of the embodiments.However, it will also be apparent to one skilled in the art that theembodiments may be practiced without the specific details. Furthermore,well-known features may be omitted or simplified in order not to obscurethe embodiment being described.

Techniques described and suggested herein relate to policy control forsystems in which one system is able to submit, on behalf of an entity,requests to another system. In an embodiment, a service providercomprises a plurality of services, each service corresponding to asystem that performs operations as part of a service offering. Theservices may be collectively configured so one or more services are ableto successfully have requests fulfilled by other services on behalf ofcustomers despite the customers not having themselves originated therequests. In this manner, services interact with one another to providea robust offering of services.

In various embodiments, customers of the service provider canprogrammatically interact (e.g., through application programminginterface (API) calls over a network) with the services for utilizationthereof. In some instances, a request from a customer may trigger one ormore other requests from one service to another. A customer may, forinstance submit a first request to a first service and fulfillment ofthe request may include submission, by the first service, of one or moresecond requests to one or more second services. One or more of the oneor more second services may themselves each submit a request to one ormore third services as a result of having received a correspondingsecond request. Generally, a single customer request may trigger variousrequests among a set of services of the service provider.

Various techniques described and suggested herein allow customers of aservice provider control over conditions that must be met before arequest from one service to another service is fulfillable. In someexamples, customers are provided an API through which the customers canprogrammatically configure policies applicable to computing resources ofthe customers. A policy of a customer may state one or more conditionsrequired to be satisfied for a request from one service to another onbehalf of the customer to be fulfilled and/or one or more conditionsrequired to be satisfied for a request from one service to another onbehalf of the customer to be denied. In this manner, customers cancontrol which services are able to successfully have requests fulfilledby other services, when such requests are fulfillable and, generally,when services are able to act on behalf of the customers.

In some embodiments, a first request from a customer to a first serviceprovider is evaluated using an authentication service, which may be aservice of the service provider. The authentication service may evaluatean electronic signature of the first request and provide informationindicative of whether the electronic signature is valid. Theauthentication service may also provide other information that enablesthe submission of requests from the first service to one or more otherservices such that the requests will be fulfilled. For example, theauthentication service may provide information enabling the firstservice to digitally sign requests to one or more other services. Theinformation may also enable another service to distinguish a requestfrom the first service from a request from another service or from thecustomer. In addition, the information may enable another service todetermine a set of services associated with a received request, wherethe association is due to having submitted an earlier request thatcaused submission of the received request. For example, if a customersubmits a request to a first service and, as a result, the first servicesubmits a second request to a second service and, as a result, thesecond service submits a third request to a third service, the thirdservice is able to determine that the third request is associated withthe customer, the first service, and the second service as a result ofthe first, second, and third requests. In this manner, the third serviceis able to evaluate policy (itself or by communication with a policyevaluation service) that may apply to such requests.

FIG. 1 shows an illustrative example of an environment in which variousembodiments can be practiced. In the environment 100 of FIG. 1, a user102 communicates with various services which may be services of aservice provider and, as discussed in more detail below, services of acomputing resource service provider. As illustrated in FIG. 1, the user102 communicates with a first service 104 and a second service 106. Eachof the services 104 and 106 may be computer systems configured toperform operations in accordance with a service offering of a provider.It should be noted that the term “service” is used both to refer tocomputer systems that are configured to provide an offering of a serviceprovider as well as the offering itself, and the meaning of the term“service” should be clear from context. Further, while the figures showusers as human operators, it should be noted that users may be automatedoperators, such as processes executing on a computing device.

Communication by the user 102 with a service may occur through anappropriate computing device. For example, the user 102 may submitrequests to the first service 104 and/or second service 106 utilizing anappropriate computing device such as a personal or laptop computer,mobile device, tablet computing device, electronic book reader andgenerally any device configured to submit electronic requests over anetwork. Further, as noted, one or both of the first service 104 andsecond service 106 may be services of a computing resource serviceprovider. Customers of the computing resource service provider mayutilize computing resource services to provide their own services and/orto configure computer systems that perform various operations in supportof their activities. As an illustrative example, the first service 104may be a virtual computer system service that hosts virtual computersystems that are programmatically managed by customers. The secondservice 106 may be a data storage service that hosts data storagedevices and stores data on behalf of customers of the computing resourceservice provider. Other types of services, including some enumeratedbelow, are considered as being within the scope of the presentdisclosure.

The user 102 may be a customer of the computing resource serviceprovider and communications from the user 102 to the first service 104and second service 106 may be pursuant to utilization of the services ofthe computing resource service provider. Requests from user 102 may bemade, for example, to configure one or more computing resources hostedby the first service 104 and for second service 106. Requests from user102 may also be submitted for other reasons such as for accessing dataprovided by the first service 104 and/or second service 106 and,generally, for other purposes. In other examples, the user 102 is acustomer of a customer of the computing resource service provider. Afirst customer of the computing resource service provider may forinstance utilize services of the computing resource service provider toprovide a website and/or a backend system for a mobile application.Requests may originate from the user 102 (a second customer, being acustomer of the first customer) for the purposes of accessing thewebsite and/or backend system. Generally requests may be submitted forvarious purposes which vary among various embodiments.

As illustrated in FIG. 1, the user 102 submits requests to the firstservice 104 and to the second service 106. A request from the user 102to the first service 104 may cause, as part of fulfillment of therequest, the first service 104 to submit one or more requests to one ormore other services, such as, as illustrated in FIG. 1, a request to thesecond service 106. The first service may, for instance, submit therequest to the second service synchronously with processing of theuser's request. The scope of the present disclosure, however, alsoextends to embodiments where the first service 104 submits a request onbehalf of the user 102 asynchronously with any request from the user102.

In an embodiment, as illustrated in the figure, the second service 106operates differently depending on the originator of a request. In thisparticular example, as illustrated in FIG. 1, the second service 106fulfills requests submitted directly from the user 102 and deniesrequests from the first service 104. In other words, the second service106 is configured to distinguish between requests submitted by a user102 and requests submitted by another entity on behalf of the user 102.The first service 104 may for instance and as discussed in more detailbelow, be prohibited by policy from submitting requests to the secondservice 106 on behalf of the user 102. Thus, while the first service 104may be operating on behalf of the user 102, the request is denied. Itshould be noted that the particular denial illustrated in FIG. 1 isillustrative and numerous variations are considered as being within thescope of the present disclosure. As noted for instance, some requestsfrom the first service to the second service may be allowed whensubmitted on behalf of the user 102. Further, as discussed in moredetail below, the fulfillment of a request may involve numerous servicesof a computing resource service provider and a request received by aservice may have passed through multiple services.

FIG. 2 shows an illustrated example of an environment 200 in whichvarious embodiments of the present disclosure may be practiced. In theenvironment 200, a computing resource service provider 202 may provide avariety of services to a customer 204. The customer 204 may be anorganization that may utilize the various services provided by thecomputing resource service provider 202 to maintain and deliverinformation to its employees, which may be located in variousgeographical locations. Additionally, the customer 204 may be anindividual that could utilize the various services to deliver content toa working group located remotely. As illustrated in FIG. 2, the customer204 may communicate with the computing resource service provider 202through one or more communications networks 206, such as the Internet.Some communications from the customer 204 to the computing resourceservice provider 202 may cause the computing resource service provider202 to operate in accordance with various techniques described herein orvariations thereof.

As noted above, a computing resource service provider 202 may providevarious computing resource services to its customers. The servicesprovided by the computing resource service provider, in this example,include a virtual computer system service 208, a block-level datastorage service 210, a cryptography service 212 (also referred to as akey management service), an on-demand data storage service 214, and oneor more other services 218, although not all embodiments of the presentdisclosure will include all such services and additional services may beprovided in addition to or as an alternative to services explicitlydescribed herein. Each of the services may include one or more webservice interfaces that enable the customer 204 to submit appropriatelyconfigured API calls to the various services through web servicerequests. In addition, each of the services may include one or moreservice interfaces that enable the services to access each other (e.g.,to enable a virtual computer system of the virtual computer systemservice 208 to store data in or retrieve data from the on-demand datastorage service and/or to access one or more block-level data storagedevices provided by the block data storage service). In someembodiments, the customers and services utilize the same interface tosubmit requests to a service.

The virtual computer system service 208 may be a collection of computingresources (e.g., collection of devices) configured to instantiatevirtual machine instances onto virtual computing systems on behalf ofthe customers 204 of the computing resource service provider 202.Customers 204 of the computing resource service provider 202 mayinteract with the virtual computer systems' service (via appropriatelyconfigured and authenticated API calls) to provision and operate virtualcomputer systems that are instantiated on physical computing deviceshosted and operated by the computing resource service provider 202. Thevirtual computer systems may be used for various purposes, such as tooperate as servers supporting a website, to operate businessapplications or, generally, to serve as computing power for thecustomer. Other applications for the virtual computer systems may be tosupport database applications, electronic commerce applications,business applications and/or other applications.

The block-level data storage service 210 may comprise a collection ofcomputing resources that collectively operate to store data for acustomer 204 using block-level storage devices (and/or virtualizationsthereof). The block-level storage devices of the block-level datastorage service 210 may, for instance, be operationally attached tovirtual computer systems provided by the virtual computer system service208 to serve as logical units (e.g., virtual drives) for the computersystems. A block-level storage device may enable the persistent storageof data used/generated by a corresponding virtual computer system wherethe virtual computer system service 208 may only provide ephemeral datastorage.

As illustrated in FIG. 2, the computing resource service provider 202may operate a cryptography service 212, which is described in moredetail below in connection with FIG. 3. Generally, the cryptographyservice may be a collection of computing resources collectivelyconfigured to manage and use cryptographic keys for customers of thecomputing resource service provider. Keys used by the cryptographyservice 212 may have associated identifiers that the customers canreference when submitting requests to perform cryptographic operations(such as encryption, decryption and message signing) and/or otheroperations, such as key rotation. The cryptography service may securelymaintain the cryptographic keys to avoid access by unauthorized parties.Customers and/or other services of the computing resource serviceprovider may specify, using key identifiers, keys to be used inperforming cryptographic operations. Further, the cryptography service212 may perform cryptographic operations using an implicitly defined(e.g., default) key for a customer and/or service. As an example, a datastorage service may submit requests to the cryptography service 212 toencrypt encryption keys used to encrypt data stored by the data storageservice and the cryptography service 212 may use a default master keyfor the data storage service.

The computing resource service provider 202 may also include anon-demand data storage service. The on-demand data storage service 214may be a collection of computing resources configured to synchronouslyprocess requests to store and/or access data. The on-demand data storageservice 214 may operate using computing resources (e.g., databases) thatenable the on-demand data storage service 214 to locate and retrievedata quickly, so as to allow data to be provided in responses torequests for the data. For example, the on-demand data storage servicemay maintain stored data in a manner such that, when a request for adata object is retrieved, the data object can be provided (or streamingof the data object can be initiated) in a response to the request. Asnoted, data stored in the on-demand data storage service 214 may beorganized into data objects. The data objects may have arbitrary sizesexcept, perhaps, for certain constraints on size. Thus, the on-demanddata storage service 214 may store numerous data objects of varyingsizes. The on-demand data storage service 214 may operate as a key valuestore that associates data objects with identifiers of the data objectswhich may be used by the customer 204 to retrieve or perform otheroperations in connection with the data objects stored by the on-demanddata storage service 214. The on-demand data storage service 214 mayalso be accessible to the cryptography service 212. For instance, insome embodiments, the cryptography service utilizes the on-demand datastorage service to store keys of the customers in encrypted form, wherekeys usable to decrypt the customer keys are accessible only toparticular devices of the cryptography service 212. Access to the datastorage service by a customer, another service, or other entity may bethrough appropriately configured API calls.

In the environment illustrated in FIG. 2, a notification service 216 isincluded. The notification service 216 may comprise a collection ofcomputing resources collectively configured to provide a web service orother interface and browser-based management console that can be used tocreate topics customers want to notify applications (or people) about,subscribe clients to these topics, publish messages, and have thesemessages delivered over clients' protocol of choice (i.e., HTTP, email,SMS, etc.). The notification service may provide notifications toclients using a “push” mechanism without the need to periodically checkor “poll” for new information and updates. The notification service maybe used for various purposes such as monitoring applications executingin the virtual computer system service, workflow systems, time-sensitiveinformation updates, mobile applications, and many others.

The computing resource service provider 202 may additionally maintainone or more other services 218 based on the needs of its customers 204.For instance, the computing resource service provider 202 may maintain adatabase service for its customers 204. A database service may be acollection of computing resources that collectively operate to run oneor more databases for one or more customers 204. Customers 204 of thecomputing resource service provider 202 may operate and manage adatabase from the database service by utilizing appropriately configuredAPI calls. This, in turn, may allow a customer 204 to maintain andpotentially scale the operations in the database. Other servicesinclude, but are not limited to, object-level archival data storageservices, services that manage and/or monitor other services and/orother services.

As illustrated in FIG. 2, the computing resource service provider 202,in various embodiments, includes an authentication service 220 and apolicy management service 222. The authentication service, in anembodiment, is a computer system (i.e., collection of computingresources) configured to perform operations involved in authenticationof users of the customer. For instance, one of the services may provideinformation from the users to the authentication service to receiveinformation in return that indicates whether or not the user requestsare authentic. Determining whether user requests are authentic may beperformed in any suitable manner and the manner in which authenticationis performed may vary among the various embodiments. For example, insome embodiments, users electronically sign messages (i.e., computersystems operated by the users electronically sign messages) that aretransmitted to a service. Electronic signatures may be generated usingsecret information (e.g., a private key of a key pair associated with auser) that is available to both an authenticating entity (e.g., user)and the authentication service. The request and signatures for therequest may be provided to the authentication service which may, usingthe secret information, compute a reference signature for comparisonwith the received signature to determine whether the request isauthentic. Message verification may also be performed using asynchronouscryptography and the keys used by the various parties may be selectedaccordingly.

If the request is authentic, the authentication service may provideinformation to the service that the service can use to determine whetherto fulfill a pending request and/or to perform other actions, such asprove to other services, such as the cryptography service, that therequest is authentic, thereby enabling the other services to operateaccordingly. For example, the authentication service may provide a tokenthat another service can analyze to verify the authenticity of therequest. Electronic signatures and/or tokens may have validity that islimited in various ways. For example, electronic signatures and/ortokens may be valid for certain amounts of time. In one example,electronic signatures and/or tokens are generated based at least in parton a function (e.g., a Hash-based Message Authentication Code) thattakes as input a timestamp, which is included with the electronicsignatures and/or tokens for verification. An entity verifying asubmitted electronic signature and/or token may check that a receivedtimestamp is sufficiently current (e.g., within a predetermined amountof time from a current time) and generate a reference signature/tokenusing for the received timestamp. If the timestamp used to generate thesubmitted electronic signature/token is not sufficiently current and/orthe submitted signature/token and reference signature/token do notmatch, authentication may fail. In this manner, if an electronicsignature is compromised, it would only be valid for a short amount oftime, thereby limiting potential harm caused by the compromise. Itshould be noted that other ways of verifying authenticity are alsoconsidered as being within the scope of the present disclosure.

The policy management service 222, in an embodiment, is a computersystem configured to manage policies on behalf of customers of thecomputing resource service provider. The policy management service 222may include an interface that enables customers to submit requestsrelated to the management of policy. Such requests may, for instance, berequests to add, delete, change or otherwise modify policy for thecustomer or for other administrative actions, such as providing aninventory of existing policies and the like. The policy managementservice 222 may also interface with other services to enable theservices to determine whether the fulfillment of a pending request isallowable according to policy corresponding to the customer for whichthe request was made. For example, when a service receives a request,the service (if it has not locally cached such information) may transmitinformation about the request (and/or the request itself) to the policymanagement system which may analyze policies for the customer todetermine whether existing policy of the customer allows fulfillment ofthe request and provide information to the service according to thedetermination.

It should be noted that, as with all embodiments explicitly illustratedherein, variations are considered as being within the scope of thepresent disclosure. For example, some or all operations performed by theauthentication service 220 and policy management service 222 may becombined into a single service. A single service may, for example,receive requests to verify pending customer requests and, as part ofverifying pending customer requests, may determine whether electronicsignatures are valid and whether any applicable policies preventfulfillment of the request (or whether any applicable policies allowfulfillment of the request where such is required for fulfillment).Further, one or more operations performed by the authentication service220 and/or the policy management service 222 may be performed by otherservices themselves without communication with the authenticationservice 220 or policy management service 222. Services may, forinstance, have their own authentication and/or policy evaluationengines, where the authentication and/or policy evaluation engines maybe updated by a central authentication service 220 and/or policymanagement service 222.

As discussed above, various embodiments of the present disclosure aredirected to providing cryptography services. Cryptography services maybe provided by a cryptography service system such as described above.FIG. 3 accordingly shows an illustrative example of a cryptographyservice 300 in accordance with various embodiments. As illustrated inFIG. 3 and as discussed above, the cryptography service 300 is logicallycomprised of a frontend system and a backend system. Both the frontendsystem and the backend system may be implemented by one or more computersystems configured to perform operations described herein. For example,as illustrated in FIG. 3, the frontend system of the cryptographyservice 300 implements a request API and a policy configuration API. Therequest API, in an embodiment, is an API configured for requestingcryptographic and other operations to be performed by the cryptographyservice. Thus, requests may be made to the frontend system via therequest API in order for such cryptographic operations to be performedby the cryptography service.

The request API may be configured with the following example,high-level, requests available:

CreateKey(KeyID)

Encrypt(KeyID, Data, [AAD])

Decrypt(KeyID, Ciphertext, [AAD])

Shred(KeyID)

ReKey(Ciphertext, OldKeyID, NewKeyID).

A CreateKey(KeyID) request, in an embodiment, causes the cryptographyservice to create a key identified by the KeyID identified in therequest. Upon receipt of a request, the cryptography service maygenerate a key and associate the key with the KeyID. It should be knownthat KeyID's may be, but are not necessarily unique identifiers. Forinstance, a KeyID may identify a family of keys. For example, in someembodiments, key rotation is performed. Key rotation may involvereplacing keys with other keys to prevent collection of enough decrypteddata to allow practical cracking of a cipher used. If performed at thedirection of an entity different from the cryptography service, use ofthe CreateKey(KeyID) request may cause the cryptography service tocreate a new key to replace an old key identified by the KeyID. The oldkey may remain identified by the KeyID, but may, for instance, be onlyused for decryption (of data that has already been encrypted using theold key) and not for future encryption. As another example, in someembodiments, users of the cryptography service provide their own keyidentifiers and there is a possibility that two different customers mayprovide the same identifier.

In such instances, the identifier may not uniquely identify a key oreven uniquely identify a family of keys. Various measures may be inplace to address this. For example, an identity or other informationassociated with a user of the cryptography service may be used toidentify the proper key or family of keys. In still other embodimentsthe cryptographic service may assign a KeyID randomly, sequentially, orusing any other method.

It should be noted that, when a KeyID does not uniquely identify a key,various systems may be in place to enable proper functionality. Forexample, in various embodiments, a family of keys identified by a KeyIDis finite. If a decryption operation using a key identified by a KeyIDis requested, additional data (e.g., a time stamp of when the encryptionwas performed) may enable determining the proper key to use. In someembodiments, ciphertexts may include information indicating a keyversion. In some embodiments, all possible keys are used to providedifferent decryptions of the data. Since there are a finite number ofkeys, the proper decryption may be selected from those provided. In someembodiments, decryption with a key is performed in a manner that enablesthe cryptographic service to detect that the ciphertext was notgenerated based at least in part on the key, such as by usingauthenticated encryption. Other variations are also considered as beingwithin the scope of the present disclosure.

An Encrypt(KeyID, Data, [AAD]) request may be used to cause thecryptography service to encrypt the specified data using a keyidentified by the KeyID. Additional Authenticated Data (AAD) may be usedfor various purposes and may be data that is not necessarily encrypted,but that is authenticated, e.g., by an electronic signature, a messageauthentication code or, generally, a keyed hash value included with theAAD. In some embodiments, the ciphertext is generated including at leasta portion of the AAD. In some other embodiments the AAD is providedseparately during decryption. In some other embodiments, the AAD isgenerated at decryption time based at least in part on the request andor other metadata such that decryption will only succeed when themetadata passes. In some embodiments, policy may constrain whether acryptographic operation can be performed with respect to particular AAD.Processing of Encrypt(KeyID, Data, [AAD]) requests may require, byprogramming logic and/or policy enforced by the cryptography service,both that the AAD contain particular values and that the AAD beauthentic (e.g., not modified since original transmission). Similarly, aDecrypt(KeyID, Ciphertext, [AAD]) request may be used to cause thecryptography service to decrypt the specified ciphertext using a keyidentified by the KeyID. The AAD in the Decrypt(KeyID, Ciphertext,[AAD]) request may be used such as described above. For instance,processing of the Decrypt(KeyID, Ciphertext, [AAD]) may require, byprogramming logic and/or policy enforced by the cryptography service,both that the AAD contain particular values and that the AAD beauthentic (e.g., not modified since original transmission).

The Shred(KeyID), in an embodiment, may be used to cause thecryptography service to electronically shred a key or family of keysidentified by the specified KeyID. Electronic shredding may includemaking the key no longer accessible. For example, use of theShred(KeyID) request may cause the cryptography system to command one ormore hardware devices to perform a SecureErase operation on one or morekeys identified by the specified KeyID. Generally, the key(s) identifiedby the KeyID may be electronically shredded in any suitable manner, suchas by overwriting data encoding the key with other data (e.g., a seriesof zeros or ones or a random string). If the key(s) are stored encryptedunder a key, the key used to encrypt the keys may be electronicallyshredded, thereby causing a loss of access to the key(s). In someembodiments, the shred operation may cause decrypt operations indicatingthe shredded KeyID to fail at some determined point in the future. Othermanners of securely and permanently destroying any possible access tothe key(s) may be used.

The ReKey(Ciphertext, OldKeyID, NewKeyID) request, in an embodiment, maybe used to cause the cryptography service to encrypt ciphertext under adifferent key. When the cryptography service receives aReKey(Ciphertext, OldKeyID, NewKeyID) request, it may use a keyidentified by the OldKeyID to decrypt the specified ciphertext and thenuse a key identified by the NewKeyID to encrypt the decryptedciphertext. If a key identified by the NewKeyID does not yet exist, thecryptography service may generate a key to use and associate thegenerated key with the specified NewKeyID, such as described inconnection the Create(KeyID) request described above. In someembodiments, the ReKey operation may be operable to cause data to betransferrable between isolated instances of a cryptography service. Insome embodiments, a policy might permit a rekey operation to beperformed on a ciphertext but might not permit the same requestor todirectly decrypt the ciphertext. In some embodiments, ReKey mightsupport rekeying a ciphertext from a key identified by a first KeyIDwithin a first account to a key identified by a KeyID within a secondaccount.

Similarly, the frontend system may implement a policy configuration APIwhich, in an embodiment, enables users to submit requests forconfiguring policies for the performance of cryptographic operations andfor other policy-related operations. Policies may be associated withkeys, groups of keys, accounts, users and other logical entities invarious embodiments. Example policies, which may be configured via thepolicy configuration API, are provided below. In an embodiment, thecryptography service policy configuration API includes the followingrequests:

SetKeyPolicy(KeyID, Policy)

Suspend(KeyID, Public Key)

Reinstate(KeyID, Private Key).

In an embodiment, the SetKeyPolicy(KeyID, Policy) request may be used tocause the cryptography service to store a policy on the key (or familyof keys) identified by the KeyID. A policy may be information that isdeterminative of whether a requested cryptographic operation can beperformed in a particular context. The policy may be encoded in adeclarative access control policy language, such as eXtensinble AccessControl Markup Language (XACML), Enterprise Privacy AuthorizationLanguage (EPAL), Amazon Web Services Access Policy Language, MicrosoftSecPol or any suitable way of encoding one or more conditions that mustbe satisfied for a cryptographic operation to be performed. Policies maydefine what operations can be performed, when the operations can beperformed, which entities can make authorized requests for operations tobe performed, which information is required for a particular request tobe authorized, and the like. In addition, policies may be defined and/orenforced using access control lists, privileges associated with users,and/or operation bitmasks in addition to or instead of the examplesgiven above. Example policies appear below.

In some embodiments the cryptographic service may support a suspendoperation, e.g., using a Suspend(KeyID, Public Key) API call. A suspendoperation enables the customer of the cryptographic service to deny theoperator of the cryptographic service use of or access to a key. Thiscan be useful to customers concerned about covert lawful orders or othercircumstances in which the operator of the cryptographic service mightbe compelled to perform some operation using a key. It may also beuseful to customers that wish to lock particular data and render itinaccessible online. In some embodiments, a suspend operation mightinclude receiving a public key from a customer and encrypting the keyspecified by a given KeyID with the received public key and shreddingthe key specified by the KeyID, such that the provider is not able toaccess the suspended key unless the private key associated with thepublic key is provided, e.g., using a Reinstate(KeyID, Private Key) APIcall that both specifies the KeyID and includes the private key. In someother embodiments, a suspend operation might involve encrypting a keyassociated with a specified KeyID using another key managed by thecryptographic service, including without limitation one created for thepurpose of the instant suspend operation. The ciphertext produced bythis operation can be provided to the customer and not retained withinthe cryptographic service. The original key identified by the KeyID canthen be shredded. The cryptographic service may be operable to receivethe provided ciphertext and re-import the suspended key. In someembodiments the ciphertext may be generated in a manner that willprevent the cryptographic service from returning a decrypted version tothe customer.

As illustrated in FIG. 3, the cryptography service 300 includes abackend system 302 that itself comprises various components in someembodiments. For example, the backend system in this example includes arequest processing system (unit) 304 which may be a subsystem of thecryptography service 300 that is configured to perform operations inaccordance with requests received through either the request API 306 orthe policy configuration API 308. For example, the request processingcomponent may receive requests received via the request API and thepolicy configuration API determines whether such requests are authenticand are therefore fulfillable and may fulfill the requests. Fulfillingthe request may include, for example, performing and/or having performedcryptographic operations. The request processing unit may be configuredto interact with an authentication interface 310 which enables therequest processing unit to determine whether requests are authentic. Theauthentication interface may be configured to interact with anauthentication service such as described above. For example, when arequest is received by the request processing unit, the requestprocessing unit may utilize the authentication interface to interactwith an authentication service which may, if applicable, provideauthentication proof that may be used in order to cause a performance ofcryptographic operations.

The backend system of the cryptography service 300 also, in thisillustrative example, includes a plurality of a security modules 312(cryptography modules), a policy enforcement module 314, and acoordinator module 316. An example coordinator module 316 is thesecurity module coordinator 1604 discussed below in connection with FIG.16. Returning to FIG. 3, one or more of the security modules may behardware security modules although, in various embodiments, a securitymodule may be any suitable computer device configured according to havecapabilities described herein. Each security module in an embodimentstores a plurality of keys associated with KeyIDs. Each security modulemay be configured to securely store the keys so as to not be accessibleby other components of the cryptography service 300 and/or othercomponents of other systems. In an embodiment, some or all of thesecurity modules are compliant with at least one security standard. Forexample, in some embodiments, the security modules are each validated ascompliant with a Federal Information Processing Standard (FIPS) outlinedin FIPS Publication 140-1 and/or 140-2, such as one or more securitylevels outlined in FIPS Publication 140-2. In addition, in someembodiments, each security module is certified under the CryptographicModule Validation Program (CMVP). A security module may be implementedas a hardware security module (HSM) or another security module havingsome or all capabilities of an HSM. In some embodiments, a validatedmodule is used to bootstrap operations. In some embodiments, customerscan configure some keys that are stored in and operated on only byvalidated modules and other keys that are operated on by software. Insome embodiments, the performance or cost associated with these variousoptions may differ.

The security modules may be configured to perform cryptographicoperations in accordance with instructions provided by the requestprocessing unit. For example, the request processing unit may provideciphertext and a KeyID to an appropriate security module withinstructions to the security module to use a key associated with theKeyID to decrypt the ciphertext and provide in response the plaintext.In an embodiment, the backend system of the cryptography service 300securely stores a plurality of keys forming a key space. Each of thesecurity modules may store all keys in the key space; however,variations are considered as being within the scope of the presentdisclosure. For example, each of the security modules may store asubspace of the key space. Subspaces of the key space stored by securitymodules may overlap so that the keys are redundantly stored throughoutthe security modules. In some embodiments, certain keys may be storedonly in specified geographic regions. In some embodiments, certain keysmay be accessible only to operators having a particular certification orclearance level. In some embodiments certain keys may be stored in andused only with a module operated by a particular third party providerunder contract with the provider of data storage services. In someembodiments, constructive control of security modules may require thatlawful orders seeking to compel use of keys other than as authorized bythe customer to involve either additional entities being compelled oradditional jurisdictions compelling action. In some embodiments,customers may be offered independent options for the jurisdiction inwhich their ciphertexts are stored and their keys are stored. In someembodiments, security modules storing keys may be configured to provideaudit information to the owner of the keys, and the security modules maybe configured such that the generation and providing of auditinformation not suppressible by the customer. In some embodiments, thesecurity modules may be configured to independently validate a signaturegenerated by the customer such that the provider (e.g., hosting thesecurity modules) is not able to perform operations under keys stored bythe security modules. In addition, some security models may store all ofthe key space and some security modules may store subspaces of the keyspace. Other variations are also considered as being the scope of thepresent disclosure. In instances where different security modules storedifferent subspaces of the key space, the request processing unit may beconfigured such as with a relational table or other mechanism todetermine which security module to instruct to perform cryptographicoperations in accordance with various requests.

In an embodiment, the policy enforcement module is configured to obtaininformation from a request processing unit and determine, based at leastin part on that information, whether the request received through theAPI may be performed. For example, when a request to performcryptographic operation is received through the request API, the requestprocessing unit may interact with the policy enforcement module todetermine whether fulfillment of the request is authorized according toany applicable policy such as policy applicable to a specified KeyID inthe request and/or other policies such as policy associated with therequestor. If the policy enforcement module allows fulfillment of therequest, the request processing unit may, accordingly, instruct anappropriate security module to perform cryptographic operations inaccordance with fulfilling the request.

As with all figures described herein, numerous variations are consideredas being within the scope of the present disclosure. For example, FIG. 3shows the policy enforcement module separate from security modules.However, each security module may include a policy enforcement module inaddition to or instead of the policy enforcement module illustrated asseparate. Thus, each security module may be independently configured toenforce policy. In addition, as another example, each security modulemay include a policy enforcement module which enforces policiesdifferent from policies enforced by a separate policy enforcementmodule. Numerous other variations are considered as being within thescope of the present disclosure.

FIG. 4 shows an illustrative example of a service 400 in accordance withvarious embodiments. The service 400 may be, for example, one of theservices described above in connection with FIG. 2. For example, theservice 400 could be a virtual computer system 208, a block data storageservice 210, a cryptography service 212, an on-demand data storageservice 214, a notification service 216, or one or more other services218 such as describe above. It should be noted that while FIG. 4illustrates various components of the service 400, the various servicewill vary in accordance with various and may include componentsdifferent than those illustrated herein. As illustrated in FIG. 4, theservice 400 includes a service frontend 402. The service frontend 402may include a collection of computing resources collectively configuredto provide an interface by which customers can communicate such asthrough application programming interface (API) calls to the frontendservice 402. The frontend service 402, for instance, may include one ormore web servers, one or more load balancers, one or more applicationservers, and generally other computing resources described herein.

In an embodiment, the service frontend 402 is configured to receivecustomer requests and provide responses to those requests. The servicefrontend 402 may also include an interface that enables the receipt andprocessing of requests from other services. In order to process therequests, the service frontend 402 may interact with various othercomponents of the service 400. For example, as illustrated in FIG. 4,the service 400 includes an authentication runtime service 404. Theauthentication runtime service 404, like the service at frontend 402,may be a subsystem of the service 400 comprising a collection ofcomputing resources collectively configured to make determinationsregarding authentication to enable the service frontend 402 to deny orfulfill requests as appropriate. In an embodiment, when the servicefrontend 402 receives a request the service frontend 402 communicateswith the authentication runtime service 404 to determine whether therequest is authentic. The request may, for instance, include anelectronic signature generated using a secret shared among the customerand an authentication service such as described above in connection withFIG. 2. The authentication runtime service 404 may transmit informationvia an authentication service interface 406 which enables theauthentication runtime service 404 to obtain determinations from anauthentication service such as described above in connection with FIG.2, whether the request is authentic. In operating to determine whetherrequests are authentic the authentication runtime service 404 may cachecertain information in order to enable the authentication runtimeservice 404 to make a determination regarding authentication withoutauthentication to an authentication service through the authenticationservice interface 406. It should be noted that while FIG. 4 illustratesa particular embodiment, the service 400 may authenticate requests inany suitable manner and not necessarily in the manner shown.

As illustrated in FIG. 4 the service frontend 402 also communicates witha policy enforcement service 408 in order to determine whether tofulfill certain requests. The policy enforcement service 408 may be asubsystem of the service 400 that comprises the collection of computingresource collectively configured to enable the service frontend 402 todetermine whether to fulfill or deny requests. As with theauthentication runtime service 404, the policy enforcement service 408may communicate with a policy management system (not illustrated in thefigure) for the purpose of determining whether fulfillment of a requestis in compliance with the policy. For example, when the service frontend402 receives a request, it may transmit the request or information basedat least in part on the request to the policy enforcement service 408.The policy enforcement service 408 may transmit information, via apolicy management system interface 410, to a policy management system inorder to make the determination. As with the authentication runtimeservice 404, the policy enforcement service 408 may cache variousinformation in order to enable determinations of whether fulfillment ofrequests comply with policies without communicating with the policymanagement system.

In various embodiments, the service frontend 402 also communicates witha service network 412 when received requests are determined to be bothauthentic and fulfillable in compliance with policy. The service network412 may be a subsystem of the service 400 comprising a collection ofcomputing resources configured to operate in support of providing aservice. For example, in an embodiment whether the service 400 is avirtual computer system service, the service network 412 may comprise aplurality of physical host computing devices that implement virtualcomputer systems on behalf of customers of the service 400. Requeststhrough the service frontend 402 may relate to operation of the virtualcomputer systems implemented using the service network 412. Forinstance, requests may be submitted to the service frontend 402 for thepurpose of provisioning, deprovisioning, modifying, or otherwiseremotely managing virtual computer systems. In the example of a blockdata storage service, the service network 412 may comprise a collectionof data storage servers with corresponding data storage devices. Theservice frontend 402 may interact with the service network 412 forvarious purposes such as allocating storage space to customers,deallocating storage space for customers, and generally in connectionwith management of one or more virtual block level data storage devicesprovided by the service 400. In the example of a cryptography service,the service network 412 may include various hardware devices that enablethe secure management of cryptographic keys. For example, the servicenetwork 412 may comprise a plurality of security modules (e.g., hardwaresecurity modules) which may be devices that securely store cryptographickey material. The service network for a cryptography service may alsoinclude data storage devices for storing keys on behalf of customers andgenerally other devices supporting operation of the cryptographyservice. In the example of an on-demand data storage service, theservice network 412, as with the block data storage service, may includedata storage servers and corresponding data storage devices. The servicenetwork may also include one or more databases in order to operate askey value stores to enable the efficient location of data within theservice network 412. The service network 412 may also include otherdevices (e.g., server computer systems), such as devices that operate todurably, i.e., redundantly store data to perform garbage collectionprocesses and the like. Generally, the service network 412 may includecomputing resources applicable to the service being provided. Also,while not illustrated, the service network 412 may include appropriatenetworking devices such as routers, switches, load balancers, and otherdevices that enable the collective operation of the devices in thestorage network 412. Of course, the exact resources that are includedand their collective configuration will vary in accordance with thevarious services and the various embodiments in which they areimplemented.

FIG. 5 shows an illustrative example of a policy management service 500in accordance with various embodiments. As illustrated in FIG. 5 thepolicy management service 500 includes a policy management systemfrontend 502. The policy management system frontend 502 may beconfigured such as the service frontend 402 described above inconnection with FIG. 4. In particular, the policy management systemfrontend 502 may be configured to receive customers' requests andprovide responses to those requests. The policy management systemfrontend 502 may also be configured to receive requests from otherservices, such as for determinations whether requests are fulfillableaccording to policy. Requests to the policy management system frontend502 may be various requests in connection with the management of policyor an account of a computing resource provider. For example, a requestto the policy management system frontend may be an appropriatelyconfigured API call to add a policy, to delete a policy, to change apolicy, and generally to perform various actions in connection withpolicies, such as providing an inventory of policies and the like.Addition and/or change of policy may be accomplished through the receiptof definitions of policies, which may comprise structured sets ofinformation specifying parameters that define corresponding policies. Anillustrative example of how a policy may be organized is discussed belowin connection with FIGS. 9 and 10.

As with other frontend systems described herein, the policy managementsystem frontend 502 may include one or more webservers that performdifferent operations. For example, in an embodiment, the policymanagement system frontend 502 may include a webserver that provides,over a network such as the Internet, a console interface for managingpolicies. The console interface may be a graphical user interface (GUI)with various GUI controls that allow users to perform various actions inconnection with the management of policy. Example actions include thedefinition of policies and submission of defined policies. A user may,for instance, use various GUI controls (drop down menus, check boxes,text entry boxes and the like) for defining a policy and then interactwith the GUI to cause the webserver to submit the defined policy.Submission of the defined policy in a request (or, generally, submissionof any request transmitted via the GUI), may cause the request to betransmitted from the webserver providing the GUI to another webserverthat orchestrates the processing of the requests, such as describedbelow. The other webserver may also be available to customers forsubmission of requests directly instead of through the webserverproviding the GUI. Other variations are also considered as being withinthe scope of the present disclosure.

As with the service 400 described above in connection with FIG. 4, thepolicy management service 500 may include an authentication runtimeservice 504 and an authentication system interface 506 in order toenable the policy management system frontend 502 to fulfill or denyrequests as appropriate. As with the service frontend 402, the policymanagement system frontend 502 may interact (e.g., via appropriatelyconfigured communication signals) with various components in order toprovide policy management services. For example, as illustrated in FIG.5, the policy management system frontend 502 may utilize a notificationsystem interface 508 to communicate with a notification system such asdescribed above. The notification system may be used in order to alertusers associated with an account of certain types of activity inconnection with one or more policies of the account. For example, asnoted in more detail below, attempted additions to a set of policies forthe account may cause the policy management system 502 to cause thenotification system to provide one or more notifications of theattempted policy addition. In this manner, receipt of the notificationenables appropriate action to be taken such as when addition of a policyis improper.

The policy management system frontend 502, in an embodiment, utilizes apolicy engine 510 which may be a subsystem of the policy managementservice 500 comprising a collection of computing resources collectivelyconfigured to evaluate policy. The policy engine 510 may receive fromthe policy management system frontend 502 a request that has beenreceived and/or information based at least in part thereon. The policyengine 510 may identify any policies applicable to the request, evaluatewhether fulfillment of the request is in compliance with any applicablepolicies, and provide notification to the policy management system 502whether fulfillment of the request is in compliance with existingpolicy. The policy engine 510 may operate in various ways in accordancewith various embodiments. For instance, as discussed below, policies maybe encoded in policy documents which encode various informationregarding principals, such as users, and conditions for the principals'access to computing resources such as cryptographic keys, data objects,logical containers for data objects and other items to which policiesapply. The policy engine (or another system working in concert with thepolicy engine) may use the information in the policies to determinewhich of a set of policies apply to a particular request. For example,if a request is submitted by a particular identity identified in therequest, the policy engine may select policies applicable to thatentity. If the request involves a particular resource, the policy enginemay select policies that are applicable to the particular resource. Inaddition, as discussed in more detail below, policy documents mayinclude information that is indicative of whether the policy document iscurrently effective (i.e., whether one or more policies encoded in thepolicy document are currently enforced), such as information indicatingtime when effectiveness of one or more policies encoded in the policydocuments begins. Identifying applicable policy documents may includeselecting policy documents that are in force and disregarding policydocuments that are not in force.

The policy engine may sequentially or otherwise process the policies todetermine whether each of the selected policies allow fulfillment of therequest. The policy engine may transmit a notification (e.g., in theform of a response to a request to evaluate policy submitted by thepolicy management system frontend system 502) to the policy managementsystem frontend system 502 that indicates whether the set of policiesfor an account corresponding to the policies allows or precludesfulfillment of the request. Additional information, such one or morereasons fulfillment of the request is precluded by policy (e.g.,information identifying one or more policies that would be violated byfulfillment of the request and/or information based at least in part onthe policies that would be violated by fulfillment of the request).

To enable large scale policy management for multiple users, the policymanagement service 500 may include a policy repository 512 which maycomprise one or more data storage devices that store policy documentsthat encode policies of the various accounts of computing resourceservice provider. In some embodiments, the policy repository 512 storespolicies for multiple entities (e.g., customers of a computing resourceservice provider) and, accordingly, stores policies in direct orindirect association with the entities to which the policies correspond.

As illustrated in FIG. 5, the policy management system frontend 502 uponreceipt of a request may utilize the authentication runtime service 504to determine whether the request is authentic. If the request isauthentic, the policy management system frontend 502 may submit a policyevaluation request to the policy engine 510 to determine whether therequest is in compliance with applicable existing policy. The policyengine 510, if it does not have such information cached, may interactwith the policy repository 512 in order to obtain applicable policies.The policy engine 510 may, for example, access all policies for anaccount associated with the request from the policy repository 512 andidentify from the access policies any policies which are applicable tothe request. As noted, the policy engine may cache policies in order toavoid communication with the repository 512 which may be implementedacross a network from the policy engine 510.

For certain types of requests, the policy management system frontend 502may interact with the policy repository 512. For example, if suchactions are allowed by existing policy the policy management systemfrontend 502 may transmit new policies to the policy repository 512, maytransmit commands to the policy repository 512 to delete one or morepolicies, and/or generally to change a set of policies or an accountassociated with the request (e.g., by modifying an existing policy).

As noted above, various policies utilized by customers of a computingresource service provider may be encoded in the form of policydocuments. The policy document in an embodiment is a document, i.e.,organized collection of information, that operates as a container forone or more statements. The policy document may be a Javascript ObjectNotation (JSON), an eXtensible Markup Language (XML) document, anotherdocument using a structured markup language, or other way oforganization information. It should be noted that a policy document mayencode one or more policies that are defined by correspondingstatements. It should also be noted that a policy may include one ormore sub-policies. In other words, a policy may comprise a collection ofpolicies. For example, an account of a computing resource serviceprovider may have a policy for a data storage service (“data storageservice policy”) that comprises a plurality of individual policies, eachdefining a specific permission. Additionally, it should be noted thatthe term “policy” may have different meanings in different contexts. Asan example, the term “policy” can have a different meaning when used asan uncountable (mass) noun than when used as a countable (count) noun.For instance, a phrase such as “whether policy allows fulfillment of arequest” may be interpreted to mean whether a collection of individualpolicies allows fulfillment of the request. Also, while policy documentsare used for the purpose of illustration, other ways of encodingpolicies (e.g., by using relational tables of a relational database tostore the various information that would be encoded by a policydocument) may be used in accordance with various embodiments. Astatement may include conditions which may be any restrictions ordetails about the statement. The conditions, for example, may specifycircumstances for a policy to be in effect.

In various embodiments, policies are able to define conditions forchanging a set of policies, such as a set of policies for an account ofa computing resource service provider. A policy on policy addition(which may be referred to as a “policy addition policy”) may requirethat, to be fulfillable, a request to add a proposed policy to a set ofpolicies must be configured such that the proposed policy will notbecome effective (i.e., be enforced by a system that enforces the set ofpolicies) until a future time, such as a specified number of hours intothe future measuring from some reference point in time. The policy onpolicy addition may define the set of principals to which the policyapplies, the resources to which the policy applies, one or more otherconditions that must be fulfilled, and one or more actions in additionto denial if the conditions are not fulfilled (or, alternatively,allowance if the conditions are fulfilled). An additional action definedby the policy may, for instance, include one or more actions that resultin notification of one or more principals of a request to add a policy.A policy administrator may, for instance, allow one or more others toadd policies to a set of policies, but may configure a policy on policyaddition such that the policy administrator can add policies without arequired delay, but the allowed one or more others can only successfullyadd policies if the policies are added so as to become effective incompliance with a required delay.

FIG. 6 shows an illustrative example of an environment 600 in whichvarious embodiments can be practiced. As illustrated in FIG. 6, theenvironment 600 includes a user 602, a first service 604, and a secondservice 606, such as described above in connection with FIG. 1. Also asillustrated in the environment 600 is an authentication service 608 suchas described above. In an embodiment, the first service 604 and secondservice 606 are configured to communicate with the authenticationservice 608 in order to determine whether requests submitted to thefirst service 604 and second service 606 should be fulfilled, such asdescribed above in connection with FIG. 4. For example, in someembodiments, the user 602 submits requests with electronic signatures ofthe requests where the electronic signatures are generated by the user602 so as to be verifiable by the authentication service 608. The user602 may, for instance, electronically sign the request using acryptographic key that is held secret between the user 602 and theauthentication service 608. As another example, the user 602 may use anasymmetric electronic signature algorithm to electronically signrequests using a private key of a public-private key pair. Theauthentication service 608 may verify electronic signatures of requestsusing a public key of the public-private key pair possibly communicatingwith a certificate authority as part of the verification process.Generally, any way by which requests may be authenticated are consideredas being within the scope of the present disclosure.

In the illustrated example, when a service receives a request from theuser 602, the service transmits the request and an electronic signatureof the request to the authentication service 608. The authenticationservice 608 may verify the electronic signature and provide a responseto the service that submitted the request. The response may be based atleast in part on whether the electronic signature is valid. If theauthentication service 608 determines that the electronic signature isvalid (and in some embodiments that the request is otherwisefulfillable), the authentication service 608 may provide a response thatthe electronic signature is valid. The service may then fulfill or causeto have fulfilled the request.

In some embodiments, the service that receives the request from the user602 that is verified by the authentication service 608 fulfills therequest entirely by itself. In some embodiments, however, fulfillment ofa request may involve utilization of one or more other services bysubmitting requests to the one or more services. As illustrated in FIG.6, for example, if the user 602 submits a request to the first service604, the first service 604 may verify the request with theauthentication service 608. Fulfillment of the request 604 may includeperforming one or more operations which, as illustrated in FIG. 6 mayinclude the first service 604 submitting a request to the second service606. In an embodiment, when the second service 606 receives a requestfrom the first service 604, the second service 606 communicates with theauthentication service 608 in order to determine whether to fulfill therequest. Based at least in part on a request from the authenticationservice 608, the second service 606 may perform one or more operationsinvolved in fulfillment of the request. While FIG. 6 shows two services,fulfillment of a request may include more than two services. Forexample, the role of second service 606 in fulfillment of a request fromthe first service 604 may include submission of one or more requests toyet another service not pictured in the figure. As illustrated in FIG.6, the user 602 may, in some embodiments, submit requests directly tothe second service 606.

As illustrated in the figure, communications between services and theauthentication service 606 may be configured so as to identifyinformation about a pending request. For example, when the user 602submits a request to the first service 604, the first service 604 maytransmit a communication to the authentication service 608 indicatingthat the request was received from the customer. Further, the secondservice 606 as noted may receive requests from the first service 604and/or the user 602. Accordingly, communications from the second service606 to the authentication service 608 may indicate whether the requestbeing verified is from the first service 604 or the user 602. In thismanner, the authentication service 608 may operate differently dependingon whether the request was received from the first service 604 or theuser 602 regardless of whether the request was nevertheless on behalf ofthe user 602.

FIG. 7 shows an illustrative example of an environment 700 which may beused to implement various aspects of the disclosure. In FIG. 7, theenvironment 700 includes a customer 702 of a computing resource serviceprovider 704. The computing resource service provider may host aplurality of services such as a first service 706 and one or more otherservices 708. An authentication service 710 may be configured within theenvironment 700 with authority to manage access control with respect tothe various services of the computing resource service provider 704. Inan embodiment, the first service 706 is configured to utilize one ormore other services 708 in its operations. The first service 706 may,for example, be a service that is used by the customer 702 to managecomputing resources managed by the other services 708. The first service706 may, for instance, be configured to utilize templates for networksthat are implementable using one or more services of the computingresource service provider 704, thereby providing customers the abilityto set up networks for various purposes with less technical knowledgeand/or less effort than would otherwise be required.

In some embodiments, the environment 700 and in particular the computingresource service provider 704 is configured such that the first service706 is able to access the one or more other services 708. The otherservices 708 are able to determine whether requests from the firstservice are authentic, where authenticity may depend on requests fromthe first service 706 being submitted with proof of a pending requestfrom the customer. In some embodiments, one or more of the otherservices 708 communicate with the authentication service 710 to validaterequests from the first service 706. Further, in some embodiments, oneor more of the other services are configured to validate requests fromthe first service 706 without communication with the authenticationservice 710. In other words, the computing resource service provider 704may operate such that information from the first service 706 issufficient for authentication of requests, but determinations onauthentication is ultimately controlled by the authentication service710. For instance, instead of a single request from the customer 702causing the authentication service 710 to communicate with two separateservices, a single request from the customer 702 may result inutilization of multiple services with only one service communicatingwith the authentication service 710. In this manner, load on theauthentication service 710 is reduced, better latency with theauthentication service 710 is attained, network resources are freed upand other advantages are achieved.

Verification of a request from a service without communication with theauthentication service 710 may be accomplished through the passage ofappropriately configured information. For example, as illustrated inFIG. 7, the customer 702 may submit a request and an electronicsignature for the request to the first service 706. The electronicsignature may be generated using a customer key (key accessible to thecustomer). Upon receipt of the request and the electronic signature forthe request, the first service 706 may provide the request and theelectronic signature to the authentication service 710. Theauthentication service 710 may provide, in response to the request fromthe first service 706, an authentication response comprising anauthentication determination and additional authentication information.The additional authentication information may include a signing keyusable to sign requests to one or more other services so as to beverifiable by the one or more services (e.g., by submitting anauthentication request to the authentication service 710 to verify asignature generated using the signing key).

The additional authentication information may also include one or moretokens, where the one or more tokens may be specific to one or moreservices. A token may comprise a service-specific authenticationresponse which may be a response that a corresponding service 708 wouldreceive from the authentication service 710 if the service 708 were tosubmit the an electronic signature generated using the signing key tothe authentication service 710 itself (or information that, due to themanner in which the corresponding service is programmed, is functionallyequivalent to a response that the corresponding service 708 would havereceived from the authentication service 710 had the correspondingservice 708 submitted the signature to the authentication service 710itself). The service-specific authentication response may includeinformation specific to the corresponding service 708, such as describedabove. For instance, the service-specific authentication response mayinclude policy associated with the customer 702 and applicable to thecorresponding service 708, an attestation to the identity of thecustomer 702, and an electronic signature generated based at least inpart on a secret key shared between the corresponding service 708 andthe authentication service 710 (but lacked by other services), where theelectronic signature is usable by the corresponding service 708 toverify the authenticity of information provided in the service-specificauthentication response. The token may include a signing key that isincluded in the authentication response and/or a derivation thereof.Further, the token may be encrypted such that a corresponding service(e.g., the second service in FIG. 7) can decrypt the token, but suchthat other, non-corresponding services cannot decrypt the token due tolack of an appropriate cryptographic key. For instance, one or moretokens may be encrypted using a secret key shared exclusively betweenthe corresponding service and the authentication service.

In other words, the first service 706 receives information the same asor functionally equivalent to information that another service 708 wouldhave received in response to a communication with the authenticationservice 710 to determine whether or not to perform one or moreoperations. In addition, the token may be provided to the first servicein the form of an authentication response that another service (e.g., inthe figure, Service 2 through Service N) would have received had theother service contacted the authentication service itself. In thismanner, the first service 706 may digitally sign requests to otherservices using a signing key provided by the authentication service 710and provide, with the requests and signatures, an appropriate token toanother service utilized in fulfilling a request from the customer 702.For example, a token associated with a request from the customer maycorrespond to a second service 708 labeled in the figure as Service 2.The first service may provide the request, a signature of the requestusing a signing key from the authentication service 710 and the token tothe second service 708. In this manner, the second service 708 mayutilize the its own secret key shared with the authentication service710 to decrypt the token, obtain a signing key or derivation thereoffrom the decrypted token, and use the signing key (or derivationthereof) to determine whether the generated key matches the providedtoken.

In other words, the second service 708 is able to utilize theinformation provided from the first service 706 in order to determinewhether or not to perform one or more operations in response to acommunication from the first service 706. The second service 708therefore does not need to communicate with the authentication service710 to determine whether to fulfill the request from the first service.However, the second service is able to determine whether to perform oneor more operations under authority of the authentication service 701because of the use of secret information shared with the authenticationservice 710. In addition, the information usable by the second service708 to determine whether to perform one or more operations isinformation that the first service is unable to utilize or access due tohaving been generated using secret information that is shared by theauthentication service 710 and the second service 708, but that whichthe first service 706 lacks. Further, since the token received from thesecond service 708 from the first service 706 contains information inthe form of an authentication response that the second service 708 wouldhave received had it contacted the authentication itself to verify thesignature, the second service 708 is able to cache some or all of theinformation from a token or information derived therefrom and utilize acache for future requests from the first service.

As with all environments illustrated herein, variations are consideredas being with the scope of present disclosure. For example, in FIG. 7, afirst service communicates with an authentication service in response toa request received from a customer of a computing resource serviceprovider. It should be noted that the scope of the present disclosureextends to embodiments where a synchronous request from the customer 702does not necessarily precede the transfer of information as illustratedin FIG. 7 and variations thereof. As one illustrative example, referringto FIG. 7, the first service 706 may be an auto-scaling service thatmeasures various activity in connection with computing resources managedby the computing resource service provider and performs scalingoperations in response thereto. As one example, if a customer utilizesthe computing resource service provider to operate a website, theauto-scaling service may add or subtract web servers supporting thewebsite as appropriate. Such auto-scaling operations may be performedwithout a synchronous customer request present. That is, the operationsmay be performed in response to one or more triggers that do not includea pending request from the customer, although the customer may havesubmitted a request asynchronously (e.g., to set up auto-scaling) priorto any auto-scaling operations.

As an example of another variation as considered within the scope of thepresent disclosure, FIG. 7 illustrates certain information beingprovided to each of the other services 708. Additional information maybe included as well. For example, each of the services 708 may beprovided the tokens for each of the services 708 (or s subset thereof).Each of the services 708 may share secret information with theauthentication service that the other services 708 and the service 706lack. In this manner, the first service 706 may provide to each serviceboth information that is usable by that service to determine whether toperform one or more operations and other information that is not usableby that service (because it cannot be decrypted, e.g.). In this manner,this first service is not required to determine which service gets whichinformation and the services 708 can each make such determinations ontheir own.

FIG. 8 shows an illustrative example of a process 800 for managingaccess to computing resources in accordance with an embodiment. Theprocess 800 may be performed by any suitable system such as by aservice, discussed above, or a customer computing device. In anembodiment, the process 800 includes receiving 802 a request to performone or more operations with an electronic signature. In other words, theprocess 800 includes receiving 802 a customer request and an electronicsignature generated based at least in part on the request. Receipt 802of the request and electronic signature may be performed over a network,such as the Internet. The request and signature may be provided, forinstance, in a web service call to a system performing the process 800.In some embodiments, such as embodiments where a customer systemreceives 802 the request, the request may be received internally, suchas over an internal network or internally within a computing device.

Upon receipt 802 of the request and electronic signature, the process800 may include requesting 804 an authentication determination from anauthentication service such as described above. As discussed above,requesting 804 an authentication determination may be performed bysubmitting an authentication request to an authentication system.Accordingly, a response from the authentication service may be received806 in response to the request 804 for the authentication determination.The response from the authentication service may be analyzed and adetermination may be made 808 whether the request is authentic. Forinstance, the response may include an authentication determination, suchas discussed above, that includes an attestation to the identity of therequestor and/or a customer (if different from the requestor, such aswhen the request was received from a service on behalf of a customer)provided as a result of a positive authentication determination. Inembodiments where the request is received by a service on behalf of acustomer during fulfillment of a customer request, the response mayinclude an attestation to the existence of a pending customer requestwith information (e.g., an expiration) indicating an amount of time forwhich the attestation is valid. If it is determined 808 that thecustomer request is authentic, that is that the authentication responsefrom the authentication service allows the customer request to befulfilled, the process 800 may include fulfilling 810 the customerrequest by using a signing key and token from an authentication serviceto submit a request to another service. For instance, the process 800may include using a signing key from the authentication service responsereceived from the authentication service to sign a request to anotherservice. The request to the other service may be provided to the otherservice with a token, which may be a token specific to the otherservice. An authentication response may be provided in the token or withthe token, where the authentication response may be the same as orfunctionally equivalent to an authentication response that the one ormore services would have received themselves had the one or moreservices provided the service-wide information to the authenticationservice themselves for an authentication determination from theauthentication service.

Returning to process illustrated in FIG. 8, if it is determined 808 thatthe customer request is not authentic, then the customer request maythen be denied 816. Denial of the customer request may be performed inany suitable manner, such as by providing that the request is denied,providing one or more reasons why the request was denied, by not takingany action and/or generally in any suitable manner. As noted, variationsof process 800 and all processes described herein are considered asbeing within the scope of the present disclosure. For example,additional operations may be included in the process 800. In someembodiments, for instance, services may cache responses from anauthentication service. Accordingly, the process 800 may includechecking a cache to determine whether information usable to determineauthenticity of the customer request has been cached. An authenticationrequest to the authentication service may occur when such information isnot found in the cache. Other variations, such as policy checks todetermine whether policy allows fulfillment of the request, are alsoconsidered as being within the scope of the present disclosure.

FIG. 9 shows an illustrative example of a policy document in accordancewith an embodiment. In an embodiment, the policy document 900 encodesvarious information relevant to a policy encoded by the policy document.The policy may be encoded in a declarative access control policylanguage, such as eXtensinble Access Control Markup Language (XACML),Enterprise Privacy Authorization Language (EPAL), Amazon Web ServicesAccess Policy Language, Microsoft SecPol or any suitable way of encodingone or more conditions that must be satisfied for a request to befulfillable. As illustrated in FIG. 9, the policy document 900 includesa name 902 which may comprise a string for the policy document 900. Thename 902 may, for instance, be used to provide a convenient identifierin using human readable terms. As an example, a name 902 may be astring, for instance, to the effect of “MyDataStoragePolicy.” Also asillustrated in FIG. 9, the policy document 900 may include a version904. The version 904 may be used to track how the policy document 900changes over time as various requests are received and fulfilled toupdate policy. Each update to the policy document 900 may cause theversion 904 to be updated to a new value. The policy document 900 mayalso include an issuer 906 which may be an identifier for a user thatsubmitted a request that resulted in creation of the policy document 900having the current version.

As illustrated in FIG. 9 and noted above, the policy document 900 mayinclude one or more statements 908. Statements in a policy document maybe processed using a logical OR. As discussed in more detail below, oneor the statements 908 may encode information that indicates a futuretime when the policy encoded by the policy document 900 is to beeffective. For example, the statement may encode a time stamp for afuture time at which the policy encoded by the policy document 900 is tobe effective. A statement may encode a duration indicating an amount oftime that must pass before which the policy document 900 is to beeffective where the duration may be measured from some point in time,which may be a global time (e.g., Unix time) or which may be measuredfrom a particular event, such as submission of a request to add a policythat contains the statement or approval of the policy by a policymanagement system. Generally, the statement may encode any informationthat immediately or eventually renders determinable a future time atwhich the policy encoded by the policy document 900 becomes effective.It should be noted that statements may also contain additionalinformation that is not illustrated in the figure, such as a statementidentifier that uniquely identifies the statement (globally or withinthe policy document), and other information which may be used by apolicy management system.

As noted above, a statement may be a formal description for a permissionor, generally, a formal description of one or more conditions on accessto one or more resources. FIG. 10 accordingly, shows an illustrativeexample of a statement 1000 which may be encoded in a policy document,such as described above. As illustrated in FIG. 10, the statement 1000may include information identifying one or more principals 1002. Aprincipal may be an entity (e.g., user, computer system, or any entitythat may be granted a permission for access to a system or resourcewithin a system) to which the statement 1000 applies. As an example, acustomer of a computing resource service provider may have an account.The account may be associated with multiple subaccounts eachcorresponding to a user of the customer. Each user may have acorresponding identifier which may be includable as a principal in astatement. Principals may also be identified in other ways. For example,sets of principals may be identified by an identifier for the set. As anillustrative example, a department in an organization may have acorresponding identifier. A statement may be applicable to the usersassociated with the department by listing in the statement an identifierfor the department. Identifiers for sets of principals may be useful,for instance, when the sets are dynamically changing such as whenemployees are hired by and/or leave an organization and/or departmenttherein. Generally, sets of principals may be defined based at least inpart on characteristics of principals. Identifiers of principals mayalso be open ended. For example, information may be included thatindicate that the statement 1000 is applicable to anyone, that is to allusers capable of submitting a request on behalf of an account of acomputing resource service provider or, generally, all users.

As illustrated in FIG. 10, a statement 1000 also identifies one or moreresources 1004. Resources may be computing resources such as describedabove. Resources may, for instance, be the subject of the servicesprovided by a computing resource service provider. As an example, aresource may be a virtual computer system, may be a logical datacontainer used to associate data objects together, may be a volumeidentifier of a block level data storage device, a database, an itemstored in a database, a data object (e.g., file) and generally any typeof resource which may be provided as a service. In some embodiments, theresources are cryptographic keys, such as cryptographic keys managed bya cryptography service on behalf of customers and/or cryptographic keysused as default keys for one or more data storage services. As withprincipals, resources may be described using identifiers of sets ofresources, which may be defined based at least in part oncharacteristics of resources. For instance, in some embodiments, virtualcomputer systems are able to be associated with user generated tags thatmay be descriptive of a role fulfilled by the virtual computer systems.As an example, a group of virtual computer systems may be associatedwith a tag “web server.” Resources, accordingly, may be identified bysuch tags. As another example, a resource may correspond to a logicaldata container thereby causing the statement 1000 to be applicable anydata objects stored within the logical data container, i.e., associatedwith the logical data container. Resources (e.g., data objects) may alsobe defined by keys used to encrypt the resources. In addition to theforegoing, objects to which policy applies (e.g., principals andresources) may be based at least in part on attributes which may becommunicated using Security Assertion Markup Language (SAML) and/orattributes that are determined using a directory.

As illustrated in FIG. 10, a statement 1000 may also include one or moreconditions. The conditions, in an embodiment, are determinative ofwhether the statement in the policy document applies in a particularcontext, i.e. applies to a submitted request in the context in which itwas submitted. The conditions may utilize Boolean operators (equal, lessthan, etc.) to allow evaluation of the conditions over other values inthe statement (principal, resource, etc.) and other values in anauthorization context, which may or may not be provided in a request forwhich policy is being evaluated. Condition values can include date,time, the Internet Protocol (IP) address of the requester, an identifierof the request source, a user name, a user identifier, and/or a useragent of the requester and/or other values. Values may also be unique toa service to which the condition applies. Conditions may be logicallyconnected for evaluation using logical connectors such as AND and OR.

Statements may also encode one or more actions 1008. An encoded actionmay represent operations that occur when the condition(s) 1006 arefulfilled and/or unfulfilled. Example actions include allowing a requestto be fulfilled (e.g., allowing requested access) or denying a request.Other actions include transmission of notification in accordance withinformation encoded in the statement 1000, such as transmission of anelectronic mail message to one or more electronic mail addressesspecified in the statement 1000, publishing a notification to a topic ofa notification service and/or other actions. Accordingly, an encodedaction 1008 may include information sufficient for performing theaction. In some embodiments, statements may lack actions when, forexample, default actions are applicable.

For instance a policy management system may operate so that actions areallowed (or denied) policy cause the actions to be denied (or allowed).Defaults may be system wide or may vary (e.g., with customers selectingdefaults).

FIG. 11 shows an illustrative example of a process for processingrequests in accordance with an embodiment. The process 1100 may beperformed by any suitable system or component thereof such as a servicedescribed above and/or the policy management service 400 describedabove. In an embodiment, the process 1100 includes receiving 1102 arequest. The request may be received, for example, as an appropriatelyconfigured API call to a frontend system (e.g., comprising a web server)of a system performing the process 1100. The API call may be, forinstance, in the form of a web service call configured with variousparameters applicable to the request. Upon receipt 1102 of the request,the process 1100 may include determining 1104 whether the request isauthentic. Determining 1104 whether the request is authentic may beperformed in any suitable manner. For example, in some embodiments, therequest may be signed and, therefore have an associated electronicsignature. Accordingly, determining 1104 whether the request isauthentic may include verifying the electronic signature.

Verification of the electronic signature may be done by any suitablesystem or component thereof. For instance, referring to embodimentsdescribed above, an authentication runtime service or authenticationservice may perform the verification. It should be noted that theverification may be performed by other entities. For instance, in someembodiments, verification is not done in a distributed manner but doneby a frontend system such as described above.

Generally, any manner in which the authenticity of the request may bedetermined may be used.

If it is determined 1104 that the request is not authentic, the requestmay be denied 1106. Denying the request may be performed in any suitablemanner, such as by responding to the request with information indicatingthe denial by simply taking no action and/or by providing informationthat indicates one or more reasons why the request is denied and/oradditional information which may be necessary to enable addressing thereason for denial. If, however, it is determined 1104 that the requestis authentic, the process 1100 may include accessing 1108 one or moreapplicable policies. Accessing 1108 applicable policies may be performedby any suitable system or component thereof, such as by a policymanagement service described above. Applicable policies may be accessed,for example, by retrieving policy documents from a policy repositorysuch as described above. In some embodiments, timing informationindicating when policies become effective is used to select a subset ofpolicies from a set of policies that are applicable (e.g., a set ofpolicies that, without regards to the timing information, would apply tothe request). The selected subset may comprise those policies that havetiming information indicative of the policies in the subset currentlybeing in effect.

A determination may then be made 1110 whether applicable policies allowfulfillment of the request. A determination 1110 whether policy allowsfulfillment of the request may be performed by any suitable system suchas by a policy engine 410 described above. A policy engine or othersystem determining whether policy allows fulfillment of the request mayanalyze applicable policies to determine whether the policy allowsfulfillment of the request. As discussed, the manner in which theanalysis takes place may vary in accordance with various embodiments.For example, applicable policies or, generally, potentially applicablepolicies may be analyzed in sequence. If a policy in a sequence ofpolicy would be violated by fulfillment of a request, a determinationmay be made that policy does not allow fulfillment of the requestwithout analyzing the remainder of the sequence (if any). More complexprocessing may also be performed. For example, if a statement in apolicy document indicates that fulfillment of the request would violatepolicy encoded in the statement, a determination may be made whether anyadditional policies supersede that policy and allow fulfillment of therequest. Generally, the policies may be analyzed in any suitable manner,and the manners may vary in accordance with which the various systemsare configured and how policies are encoded. If it is determined 1110that policy does not allow the request to be fulfilled, the process 1100may include denying 1106 the request such as described above. If,however, it is determined 1110 that policy does allow fulfillment of therequest, the request may be fulfilled 1112.

As with all processes discussed herein, variations are considered asbeing within the scope of the present disclosure. For example, theprocess 1100 and other processes described herein may include additionaloperations in addition to those illustrated and/or discussed herein. Forexample, in some instances, a system, such as a policy enforcementsystem may maintain (or have maintained by another system) an audit logof requests. An audit log may be made on a system-wide basis, on acustomer-specific basis so that each customer of a service provider hasa corresponding audit log or otherwise. The audit log may recordrequests that were received by a system (e.g., computing resourceservice) and store information associated with the requests, such aswhether the requests were fulfilled, denied, unsuccessfully fulfilledand the like. Other information associated with a request stored in anaudit log may include information identifying a submitter of the request(requestor), computing resources affected by the request, informationabout when the request was received and the like. In some embodiments,when requests are received, information is written to an audit log thatidentifies one or more services that caused the request to be submitted(e.g, a via set, as discussed in more detail below). For example, if therequest was submitted by a first service as a result of having receiveda request from a second service, information may be written to the auditlog that identifies the first and second service. Such information mayindicate an order of causation of events that caused the request and/ormay include other information.

FIG. 12 shows an illustrative example of various data that may be storedby a service provider such as a computing resource service provider asdescribed above. As illustrated in FIG. 12, a service provider may storevarious types of provider stored customer data 1200. The provider-storedcustomer data 1200 may include various types of data, such asunencrypted data 1202. Unencrypted data 1202 may be data that theservice provider stores in plaintext form. A customer of the serviceprovider may, for example, upload data without having indicated that thedata should be encrypted. The data may be stored in an unencrypted formfor various reasons such as for ease of access and because the data isof a nature where data security is not an issue.

The provider-stored customer data 1200 may also include data encryptedwith customer-selected keys 1204. The data encrypted withcustomer-selected keys 1204 may be data that has been encrypted directlyor indirectly utilizing a cryptography service such as described above.For example, customers may submit requests to the cryptography serviceand the cryptography service may encrypt data specified by the requestusing keys identified by key identifiers in the request. In someembodiments, the data encrypted by the cryptography service is itselfcryptographic keys. For example, in some embodiments data is encryptedusing and encryption key. The encryption key may be provided (e.g., by acustomer or another service) to the cryptography service for encryptionby the cryptography service using a key specified by the customer wherespecification of the key may be explicit (e.g. using a key identifier asa parameter in an API call) or implicit (e.g., by default). It should benoted, however, that data may be encrypted directly by the cryptographyservice without having encrypted the data using an intermediateencryption key.

The provider-stored customer data 1200 may also include data encryptedwith provider-selected keys. Data encrypted with provider-selected keysmay be data that is encrypted using a key outside of customer's control(i.e., a key that the customer is unable to explicitly select). Forexample, in some embodiments, requests to a data storage service may besubmitted with an option for server-side encryption. In such requests,the customer specifies that the data should be encrypted and perhaps howthe data should be encrypted (e.g., which encryption algorithm or modeof an encryption algorithm to use) but the requests do not specify whichkey to use for the encryption. The provider may select a key and encryptthe data accordingly. The data may be stored in a manner such that a keythat was used to encrypt the data is obtainable so as to render the datadecryptable when appropriate, such as in response to a valid dataretrieval request. In some embodiments, for example, a data storageservice receives a request to store data using server-side encryption.The data storage service may generate or otherwise obtain an encryptionkey, encrypt the data and transmit the encryption key in a request to acryptography service. The cryptography service may use a default masterkey for the data storage service (or a key specified by the data storageservice) to encrypt the encryption key. The encrypted encryption key maybe stored with or otherwise in association with the encrypted data.Other variations where data of a customer are encrypted using a providerselected key are considered as being within the scope of the presentdisclosure.

Some or all of the types of provider-stored customer data 1200 maycomprise resources (e.g., data objects) to which one or more policiesmay be applicable. For example, a policy may state conditions for accessto certain data objects. Applicability of a policy to data may bedefined based at least in part on data object identifiers, identifiersfor logical data containers used to organize data objects, for keys usedto encrypt data objects, and the like. Further, as discussed in moredetail below, policies may be defined so as to apply to differentprincipals in different ways. For instance, a policy may allow access todata dependent at least in part on which service(s) or services (if any)are involved in fulfilling a pending request (e.g., a pending customerrequest). As an illustrative example, a policy may apply differently ifa request to which the policy is being evaluated was received from acustomer or from another service.

FIG. 13 shows illustrative examples of policies which may be used tocontrol access to computing resources such as data in accordance withvarious embodiments. The policies illustrated in FIG. 13 may beimplemented by a policy management system and/or policy evaluationengine such as described above. As with all policies the policiesillustrated in FIG. 13 may apply to one or more principals where theprincipals may correspond to human operators (e.g., users of a customer)or systems (e.g., services of a service provider). In an embodiment, anapplication programming interface may allow customers of a computingresource service provider to configure policies such as thoseillustrated in FIG. 13 on cryptographic keys managed remotely by thecustomers using the resources of the computing resource serviceprovider. Principals and/or resources to which policies apply may bedefined by one or more characteristics of the resources. For example, apolicy may apply to any users having an associated role in a system. Asanother example, a policy may apply to any data encrypted using aspecified cryptographic key managed by a cryptography service.

Turning to the specific policies illustrated in FIG. 13, a first policy1302 indicates that a request should be denied if a VIA value is notnull. As discussed, the VIA value may be a value in a token providedwith a request that indicates a service through which a request wasrouted and/or generally a service that performs one or more operationsin connection fulfillment of a request. For example, if fulfillment of acustomer request involves a request from a first service to a secondservice, a token provided from the first service to the second servicemay include an identifier of the first service as a VIA value toindicate to a policy evaluation engine the originator of the request.Similarly, if fulfillment of a customer request involves a first requestfrom a first service to a second service and fulfillment of the firstrequest involves a request transmitted from the second service to athird service, a token provided to the third service may includeidentifiers of the second service and third service as VIA values. TheVIA values may be ordered to indicate or may otherwise indicate an orderin which the requests were submitted. Thus, in the illustrative exampleof the policy 1302, a request to which the policy 1302 applies would bedisallowed by the policy 1302 if the request was received from a serviceinstead of from a user (although, in some embodiments, a policy thatdisallows or allows an action may be overridden by another applicablepolicy).

FIG. 13 also shows another policy 1304. In the example of the policy1304, a request to which the policy 1304 would be allowed if a VIA valueset includes Service 1 and would be denied otherwise (if not allowed byanother applicable policy). A VIA value set may comprise a set of VIAvalues (e.g., zero or more VIA values) encoded in a token provided witha request. It should be noted that the policies illustrated in FIG. 13may be evaluated in a context where default behavior (e.g., allow ordeny) applies, either by default system behavior or by policy.

Thus, a policy with “allow” may override a default policy of “deny” whenapplicable to a request. Similarly, a policy with “deny” may override adefault policy of “allow” when applicable to a request. Returning to theexample policy 1304, a request to which the policy 1304 applies would beallowable if fulfillment of the request involved submission of therequest from a service identified as “Service 1” (and other applicablepolicy did not supersede the policy 1304).

FIG. 13 also shows another example of a policy 1306. In the examplepolicy 1306, a request to which the policy 1306 applies would be deniedif the VIA value set contains “Service 1.” Thus, in contrast to thepolicy 1304, if fulfillment of a request involved a request submitted bya service identified as “Service 1,” the request would be denied. Suchas a policy may be set, for example, in instances where a user does nottrust the service identified as Service 1 for one or more reasons, suchas the service not having been audited and found to be compliant withone or more regulatory regimes desirable to the user.

As noted above, a token may indicate an ordering of multiple VIA values,where the ordering may correspond to an order in which requests weresubmitted. Accordingly, FIG. 13 shows another example, policy 1308 wherefulfillment of a request is allowed if a most recent VIA value is“Service 1,” that is, if the request for which the policy 1308 is beingevaluated was transmitted by Service 1. If the request was submitted byanother service, the request may be denied (e.g., unless anotherapplicable policy renders fulfillment of the request allowable).

In an example policy 1310, a request to which the policy 1310 applies isallowable by the policy 1310 if the VIA value set is equal to a sethaving one member where that member is Service 1, that is, a serviceidentified by “Service 1.” In this manner, for a request to which thepolicy 1310 applies, if the request was triggered by another request toService 1 by another service, fulfillment of the request would becontrary to the policy 1310 and, therefore, the request would be deniedunless allowable for a reason independent of the policy 1310.

An example policy 1312 indicates that a request to which the policy 1312applies is allowable if there is one or less VIA value. In this manner,for a request to which the policy 1312 applies, if fulfillment of arequest requires two services, the VIA value set would not comply withthe conditions in the policy 1312. As yet another example policy 1314, arequest to which the policy 1314 applies would be contrary to the policy1314 if the VIA value set does not equal {“Service 1,” “Service 4,”“Service 2”}. In this manner, fulfillment of request must involve aspecific sequence of use of services identified respectively as “Service1,” “Service 4” and “Service 2.”

For an example policy 1316, a request to which the policy 1316 applieswould be contrary to the policy if the VIA set provided with the requestincludes a service lacking a tag indicating compliance with a complianceregime where the compliance regime may be specified in the policy.Example compliance regimes include, but are not limited to, the HealthInsurance Portability and Accountability Act (HIPAA), InternationalTraffic in Arms Regulations (ITAR), and the Payment Card Data SecurityStandards (PCI DSS). One or more compliance regimes may be encoded inthe policy 1316 itself and/or the policy 1316 may contain a reference toone or more compliance regimes, such as a uniform resource locator (URL)or other reference to a list of one or more compliance regimesmaintained outside of the policy 1316.

It should be noted that the policies illustrated in FIG. 13 are providedfor illustrative purposes and other policies are considered as beingwithin the scope of the present disclosure. For example, policies may bedefined with more complex conditions than illustrated in FIG. 13.Conditions of a policy may, for instance, be defined using someconditions which are logically connected through, for example, Booleanoperators. In addition, the example policies provides specific examplesof policies with various conditions relating to originating systems forrequests and events causing triggers of requests (e.g., other requeststo other systems). In the example of the policy 1316, a policy isdefined based at least in part on a characteristic of a serviceassociated with a request to which the policy 1316 applies, where, inthis example, the characteristic of the service is the existence of atag associated with the service indicating compliance with a regulatoryregime. Other characteristics of services, and generally characteristicsof VIA value sets, may also be used to define policies in accordancewith the various embodiments. Further, characteristics of services, VIAvalue sets and generally characteristics of items to which a policy mayapply may be defined externally to policy, as illustrated in the exampleof a reference to a list of compliance regime(s). For such policies,evaluation of a policy may include accessing referenced information todetermine whether fulfillment of a request complies with policy.Conditions of policies may be more complex and a policy may include, inaddition to one or more conditions on a VIA value set, one or moreconditions based at least in part on the presence of a pending customerrequest. For example, a policy may allow fulfillment of a requestconditioned on the presence of a customer request, which may beverifiable by information provided in a response from an authenticationservice, such as described below. In this manner, services can beprevented from operating on behalf of a customer without explicitauthorization to do so evidenced by a request (e.g., appropriatelyconfigured API call) from the customer.

It should be noted that the policies of FIG. 13, for the purpose ofillustration, are shown without any particular syntax. Policies may beencoded in various ways, such as using a syntax suitable for a systemthat evaluates the policies where the syntax may vary in accordance withvarious embodiments. Example syntaxes are those used in policy languagesdiscussed above.

As noted above, when an authentication request is submitted from aservice or a user to an authentication service, the authenticationservice may provide a response that includes various information thatprovides various technical advantages such as efficient use of forwardaccess sessions. FIG. 14, accordingly, shows an illustrative example ofa response 1400 from an authentication service. In an embodiment, theresponse 1400 includes a signing key 1402. The signing key 1402 may be acryptographic key usable to generate an electronic signature of arequest submitted to another service such that the other service is ableto verify the electronic signature. Verification of the electronicsignature may be performed in various ways in accordance with variousembodiments. For example, in some embodiments, the electronic signatureis verifiable by submitting, with an appropriate token as discussedbelow, the electronic signature and the data of the request on which theelectronic signature was based to the authentication service or anotherservice configured with an appropriate cryptographic key for verifyingthe request which may be the same as the signing key 1402. In someembodiments, information in a token (discussed below) enables a servicethat receives a request signed by the signing key 1402 is able to verifythe request without communication with the authentication service,thereby reducing latency and reliance on another service.

As illustrated FIG. 14, a response from an authentication service mayalso include an authentication determination 1404. The authenticationdetermination 1404 may include an indication of whether a request shouldbe fulfilled, which may include an indirect indication by, for example,indicating whether an electronic signature is valid. It should be notedthat the response from the authentication service may vary based, atleast in part, on the authentication determination 1404. For example, aresponse from the authentication service may lack a signing key and/ortoken (discussed below) if the authentication determination is anegative one.

In an embodiment, the response 1400 also includes a token 1406 which maycomprise information encrypted so as to be decryptable by a service towhich the token will be submitted. In an embodiment, for example, thetoken is encrypted using a key held secretly by the authenticationservice so that the authentication service is able to decrypt the tokenwhen presented in a request. In another embodiment, the token isencrypted using a key shared secretly between the authentication serviceand another service. In this manner, when the token is presented in arequest to the other service, the other service can use its copy of thecryptographic key to decrypt the token and use the information encodedtherein. It should be noted that, while FIG. 14 shows a single token1406, a response from an authentication service may include multipletokens, each encrypted so as to be decryptable by a different service.In this manner, appropriate tokens may be selected and presentedaccordingly for submission of requests.

As illustrated in FIG. 14, the token 1406 includes various informationusable by a recipient of the token to determine whether to fulfill arequest. For example, the token 1406 may encode a VIA set, such asdescribed above. In this manner, a system evaluating policy may use theVIA set to determine whether the VIA set complies with policy. It shouldbe noted that the VIA set may be provided in plaintext form in theresponse 1400 and authenticity of the VIA set may be accomplishedthrough, for instance, an electronic signature. In the illustrativeexample of FIG. 14, the token 1406 also includes the signing key 1402(encrypted as a result of being in the token 1406). In this manner, thetoken can be decrypted by a recipient service to extract the signing key1402 and use the extracted signing key 1402 to verify an electronicsignature generated by another service using the signing key 1402.

As noted, the response 1400 illustrated in FIG. 14 is illustrative innature and variations are considered as being within the scope of thepresent disclosure. For example, information additional to that which isillustrated in the figure may be provided in the response 1400. Suchinformation may include, for instance, an expiration for the token 1406,an attestation to the existence of a pending customer request, anattestation to the identity from whom the request was submitted, anattestation to the identity of a customer on behalf of whom the requestwas submitted and/or generally any information which may be required tosatisfy one or more conditions for fulfillment of another requestsubmitted using information from the response 1400.

FIG. 15 shows an illustrative example of a process 1500 for evaluatingan authentication request in accordance with an embodiment. The process1500 may be performed by any suitable system, such by an authenticationservice described above. The process 1500 may also be performed by othersystems, such as by a local system in a service that caches informationand uses the cached information to evaluate requests. In an embodiment,the process 1500 includes receiving 1502 an authentication request froma service, which in FIG. 15 is illustratively labeled as Service K. Therequest may, for example, be received over a network of a computingresource service provider and/or one or more other networks. Uponreceipt of the request, the process 1500 may include determining 1504whether a signature of the request is valid, such as described above. Ifit is determined 1504 that the electronic signature is not valid, theprocess 1500 may include providing 1506 a response indicating DENY. Forexample, referring to FIG. 14, a response form the authenticationservice may include an authentication determination 1404 indicative thata request being verified should be denied. If it is determined 1504 thatthe signature is valid, the process 1500 may include determining 1508whether to generate a token such as described above in connection withFIG. 14.

Determining 1508 whether to generate the token may be performed invarious ways in accordance with various embodiments. For example,determining 1508 whether to generate a token may include detecting thatthe request originated from a particular service instead of from a usersuch as described above. As a result of the request being received froma service, it may be determined 1508 to generate a token. Determining1508 whether to generate a token may also be based at least in part onother factors, such as whether an authentication request indicated arequest for a token (due to the need to submit a token in a request toanother service.) It should be noted that, in some embodiments, tokensare generated for all requests for which it is determined 1504 that asignature is valid.

Returning to the illustrative embodiment of FIG. 15, if it is determined1508 that a token not be generated, the process 1500 may includeproviding 1510 a response that indicates ALLOW. If, however, it isdetermined 1508 that a token should be generated, the process 1500 mayinclude determining 1512 whether there is an existing token. Determining1512 whether there's an existing token may include, for instance,determining whether the received 1502 authentication request wassubmitted with a token. If it is determined 1512 that there is noexisting token, the process 1500 may include setting 1514 a VIA valueset to be {“Service K”}. If, however, it is determined 1512 that thereis an existing token, a VIA value set may be extracted 1516 from theexisting token and Service K may be added to the VIA value set. Once theVIA value set has been determined, the process 1500 may includegenerating 1520 a new token with the VIA value set. The generated tokenmay then be provided 1522 with a response that indicates ALLOW. Theresponse may be configured, for example, such as described above inconnection with FIG. 14.

A token received with a response such as generated in accordance withFIG. 15 may be used, as noted, to submit a request to another service.The other service may use the token (and possibly other information inthe request) to evaluate whether to fulfill the request, such as byevaluating policy based at least in part on information in a VIA valueset (or lack thereof), such as described above.

FIG. 16 illustrates aspects of an example environment 1600 forimplementing aspects in accordance with various embodiments. As will beappreciated, although a web-based environment is used for purposes ofexplanation, different environments may be used, as appropriate, toimplement various embodiments. The environment includes an electronicclient device 1602, which can include any appropriate device operable tosend and receive requests, messages or information over an appropriatenetwork 1604 and convey information back to a user of the device.Examples of such client devices include personal computers, cell phones,handheld messaging devices, laptop computers, tablet computers, set-topboxes, personal data assistants, embedded computer systems, electronicbook readers and the like. The network can include any appropriatenetwork, including an intranet, the Internet, a cellular network, alocal area network or any other such network or combination thereof.Components used for such a system can depend at least in part upon thetype of network and/or environment selected. Protocols and componentsfor communicating via such a network are well known and will not bediscussed herein in detail. Communication over the network can beenabled by wired or wireless connections and combinations thereof. Inthis example, the network includes the Internet, as the environmentincludes a web server 1606 for receiving requests and serving content inresponse thereto, although for other networks an alternative deviceserving a similar purpose could be used as would be apparent to one ofordinary skill in the art.

The illustrative environment includes at least one application server1608 and a data store 1610. It should be understood that there can beseveral application servers, layers or other elements, processes orcomponents, which may be chained or otherwise configured, which caninteract to perform tasks such as obtaining data from an appropriatedata store. Servers, as used herein, may be implemented in various ways,such as hardware devices or virtual computer systems. In some contexts,servers may refer to a programming module being executed on a computersystem. As used herein the term “data store” refers to any device orcombination of devices capable of storing, accessing, and retrievingdata, which may include any combination and number of data servers,databases, data storage devices, and data storage media, in anystandard, distributed, or clustered environment. The application servercan include any appropriate hardware and software for integrating withthe data store as needed to execute aspects of one or more applicationsfor the client device, handling some (even a majority) of the dataaccess and business logic for an application. The application server mayprovide access control services in cooperation with the data store andis able to generate content such as text, graphics, audio and/or videoto be transferred to the user, which may be served to the user by theweb server in the form of HyperText Markup Language (“HTML”), ExtensibleMarkup Language (“XML”), or another appropriate structured language inthis example. The handling of all requests and responses, as well as thedelivery of content between the client device 1602 and the applicationserver 1608, can be handled by the web server. It should be understoodthat the web and application servers are not required and are merelyexample components, as structured code discussed herein can be executedon any appropriate device or host machine as discussed elsewhere herein.Further, operations described herein as being performed by a singledevice may, unless otherwise clear from context, be performedcollectively by multiple devices, which may form a distributed system.

The data store 1610 can include several separate data tables, databasesor other data storage mechanisms and media for storing data relating toa particular aspect of the present disclosure. For example, the datastore illustrated may include mechanisms for storing production data1612 and user information 1616, which can be used to serve content forthe production side. The data store also is shown to include a mechanismfor storing log data 1614, which can be used for reporting, analysis orother such purposes. It should be understood that there can be manyother aspects that may need to be stored in the data store, such as pageimage information and access rights information, which can be stored inany of the above listed mechanisms as appropriate or in additionalmechanisms in the data store 1610. The data store 1610 is operable,through logic associated therewith, to receive instructions from theapplication server 1608 and obtain, update or otherwise process data inresponse thereto. In one example, a user, through a device operated bythe user, might submit a search request for a certain type of item. Inthis case, the data store might access the user information to verifythe identity of the user and can access the catalog detail informationto obtain information about items of that type. The information then canbe returned to the user, such as in a results listing on a web page thatthe user is able to view via a browser on the user device 1602.Information for a particular item of interest can be viewed in adedicated page or window of the browser. It should be noted, however,that embodiments of the present disclosure are not necessarily limitedto the context of web pages, but may be more generally applicable toprocessing requests in general, where the requests are not necessarilyrequests for content.

Each server typically will include an operating system that providesexecutable program instructions for the general administration andoperation of that server and typically will include a computer-readablestorage medium (e.g., a hard disk, random access memory, read onlymemory, etc.) storing instructions that, when executed by a processor ofthe server, allow the server to perform its intended functions. Suitableimplementations for the operating system and general functionality ofthe servers are known or commercially available and are readilyimplemented by persons having ordinary skill in the art, particularly inlight of the disclosure herein.

The environment in one embodiment is a distributed computing environmentutilizing several computer systems and components that areinterconnected via communication links, using one or more computernetworks or direct connections. However, it will be appreciated by thoseof ordinary skill in the art that such a system could operate equallywell in a system having fewer or a greater number of components than areillustrated in FIG. 16. Thus, the depiction of the system 1600 in FIG.16 should be taken as being illustrative in nature and not limiting tothe scope of the disclosure.

The various embodiments further can be implemented in a wide variety ofoperating environments, which in some cases can include one or more usercomputers, computing devices, or processing devices which can be used tooperate any of a number of applications. User or client devices caninclude any of a number of general purpose personal computers, such asdesktop, laptop, or tablet computers running a standard operatingsystem, as well as cellular, wireless, and handheld devices runningmobile software and capable of supporting a number of networking andmessaging protocols. Such a system also can include a number ofworkstations running any of a variety of commercially availableoperating systems and other known applications for purposes such asdevelopment and database management. These devices also can includeother electronic devices, such as dummy terminals, thin-clients, gamingsystems, and other devices capable of communicating via a network.

Various embodiments of the present disclosure utilize at least onenetwork that would be familiar to those skilled in the art forsupporting communications using any of a variety of commerciallyavailable protocols, such as Transmission Control Protocol/InternetProtocol (“TCP/IP”), protocols operating in various layers of the OpenSystem Interconnection (“OSI”) model, File Transfer Protocol (“FTP”),Universal Plug and Play (“UpnP”), Network File System (“NFS”), CommonInternet File System (“CIFS”), and AppleTalk. The network can be, forexample, a local area network, a wide-area network, a virtual privatenetwork, the Internet, an intranet, an extranet, a public switchedtelephone network, an infrared network, a wireless network, and anycombination thereof.

In embodiments utilizing a web server, the web server can run any of avariety of server or mid-tier applications, including Hypertext TransferProtocol (“HTTP”) servers, FTP servers, Common Gateway Interface (“CGP”)servers, data servers, Java servers, and business application servers.The server(s) also may be capable of executing programs or scripts inresponse to requests from user devices, such as by executing one or moreweb applications that may be implemented as one or more scripts orprograms written in any programming language, such as Java®, C, C#, orC++, or any scripting language, such as Perl, Python, or TCL, as well ascombinations thereof. The server(s) may also include database servers,including without limitation those commercially available from Oracle®,Microsoft®, Sybase®, and IBM®.

The environment can include a variety of data stores and other memoryand storage media as discussed above. These can reside in a variety oflocations, such as on a storage medium local to (and/or resident in) oneor more of the computers or remote from any or all of the computersacross the network. In a particular set of embodiments, the informationmay reside in a storage-area network (“SAN”) familiar to those skilledin the art. Similarly, any necessary files for performing the functionsattributed to the computers, servers or other network devices may bestored locally and/or remotely, as appropriate. Where a system includescomputerized devices, each such device can include hardware elementsthat may be electrically coupled via a bus, the elements including, forexample, at least one central processing unit (“CPU” or “processor”), atleast one input device (e.g., a mouse, keyboard, controller, touchscreen, or keypad), and at least one output device (e.g., a displaydevice, printer, or speaker). Such a system may also include one or morestorage devices, such as disk drives, optical storage devices andsolid-state storage devices such as random access memory (“RAM”) orread-only memory (“ROM”), as well as removable media devices, memorycards, flash cards, etc.

Such devices also can include a computer-readable storage media reader,a communications device (e.g., a modem, a network card (wireless orwired), an infrared communication device, etc.), and working memory asdescribed above. The computer-readable storage media reader can beconnected with, or configured to receive, a computer-readable storagemedium, representing remote, local, fixed, and/or removable storagedevices as well as storage media for temporarily and/or more permanentlycontaining, storing, transmitting, and retrieving computer-readableinformation. The system and various devices also typically will includea number of software applications, modules, services or other elementslocated within at least one working memory device, including anoperating system and application programs, such as a client applicationor web browser. It should be appreciated that alternate embodiments mayhave numerous variations from that described above. For example,customized hardware might also be used and/or particular elements mightbe implemented in hardware, software (including portable software, suchas applets), or both. Further, connection to other computing devicessuch as network input/output devices may be employed.

Storage media and computer readable media for containing code, orportions of code, can include any appropriate media known or used in theart, including storage media and communication media, such as, but notlimited to, volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage and/or transmissionof information such as computer readable instructions, data structures,program modules, or other data, including RAM, ROM, ElectricallyErasable Programmable Read-Only Memory (“EEPROM”), flash memory or othermemory technology, Compact Disc Read-Only Memory (“CD-ROM”), digitalversatile disk (DVD), or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devicesor any other medium which can be used to store the desired informationand which can be accessed by the system device. Based on the disclosureand teachings provided herein, a person of ordinary skill in the artwill appreciate other ways and/or methods to implement the variousembodiments.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims.

Other variations are within the spirit of the present disclosure. Thus,while the disclosed techniques are susceptible to various modificationsand alternative constructions, certain illustrated embodiments thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit theinvention to the specific form or forms disclosed, but on the contrary,the intention is to cover all modifications, alternative constructionsand equivalents falling within the spirit and scope of the invention, asdefined in the appended claims.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosed embodiments (especially in thecontext of the following claims) are to be construed to cover both thesingular and the plural, unless otherwise indicated herein or clearlycontradicted by context. The terms “comprising,” “having,” “including,”and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. The term“connected,” when unmodified and referring to physical connections, isto be construed as partly or wholly contained within, attached to orjoined together, even if there is something intervening. Recitation ofranges of values herein are merely intended to serve as a shorthandmethod of referring individually to each separate value falling withinthe range, unless otherwise indicated herein and each separate value isincorporated into the specification as if it were individually recitedherein. The use of the term “set” (e.g., “a set of items”) or “subset”unless otherwise noted or contradicted by context, is to be construed asa nonempty collection comprising one or more members. Further, unlessotherwise noted or contradicted by context, the term “subset” of acorresponding set does not necessarily denote a proper subset of thecorresponding set, but the subset and the corresponding set may beequal.

Conjunctive language, such as phrases of the form “at least one of A, B,and C,” or “at least one of A, B and C,” unless specifically statedotherwise or otherwise clearly contradicted by context, is otherwiseunderstood with the context as used in general to present that an item,term, etc., may be either A or B or C, or any nonempty subset of the setof A and B and C. For instance, in the illustrative example of a sethaving three members used in the above conjunctive phrase, “at least oneof A, B, and C” and “at least one of A, B and C” refers to any of thefollowing sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus,such conjunctive language is not generally intended to imply thatcertain embodiments require at least one of A, at least one of B and atleast one of C to each be present.

Operations of processes described herein can be performed in anysuitable order unless otherwise indicated herein or otherwise clearlycontradicted by context. Processes described herein (or variationsand/or combinations thereof) may be performed under the control of oneor more computer systems configured with executable instructions and maybe implemented as code (e.g., executable instructions, one or morecomputer programs or one or more applications) executing collectively onone or more processors, by hardware or combinations thereof. The codemay be stored on a computer-readable storage medium, for example, in theform of a computer program comprising a plurality of instructionsexecutable by one or more processors. The computer-readable storagemedium may be non-transitory.

The use of any and all examples, or exemplary language (e.g., “such as”)provided herein, is intended merely to better illuminate embodiments ofthe invention and does not pose a limitation on the scope of theinvention unless otherwise claimed. No language in the specificationshould be construed as indicating any non-claimed element as essentialto the practice of the invention.

Preferred embodiments of this disclosure are described herein, includingthe best mode known to the inventors for carrying out the invention.Variations of those preferred embodiments may become apparent to thoseof ordinary skill in the art upon reading the foregoing description. Theinventors expect skilled artisans to employ such variations asappropriate and the inventors intend for embodiments of the presentdisclosure to be practiced otherwise than as specifically describedherein. Accordingly, the scope of the present disclosure includes allmodifications and equivalents of the subject matter recited in theclaims appended hereto as permitted by applicable law. Moreover, anycombination of the above-described elements in all possible variationsthereof is encompassed by the scope of the present disclosure unlessotherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications, andpatents, cited herein are hereby incorporated by reference to the sameextent as if each reference were individually and specifically indicatedto be incorporated by reference and were set forth in its entiretyherein.

1. A system comprising: memory to store instructions that, if executedby one or more processors of the system, cause the system to: generatean authentication response by verifying an electronic signature of afirst request, the authentication response includes informationidentifying a set of computing resource services; send the first requestand the authentication response associated with the first request;utilize the authentication response, based at least in part onfulfilling the first request, to send a second request; process thesecond request according to a policy determination, the policydetermination is determined by at least evaluating a set of policiesapplicable to the second request based at least in part on theauthentication response; and send a third request, the third requestbeing processed according to a policy of the policy determination suchthat processing the policy is based at least in part on a user profileassociated with the authentication response that triggered the thirdrequest, including the first request and the second request.
 2. Thesystem of claim 1, wherein: process the second request includes use of afirst cryptographic key specified in the second request to perform oneor more cryptographic operations; process the third request includes useof a second cryptographic key specified in the third request to performone or more cryptographic operations; and the set of policies specifyone or more conditions required to be satisfied before the first andsecond cryptographic keys are usable.
 3. The system of claim 1, wherein:the first request is sent on behalf of a customer of a computingresource service provider of a first, second and third computingresource services; and the set of policies are configured such that thepolicy determination is different than the policy determination would beif the first request was received from an entity that is not a customer.4. The system of claim 3, wherein the first, second and third computingresource services further implement an application programming interfacethrough which application programming interface requests are sent, by acustomer of a computing resource service provider of the first, secondand third computing resource services, to define one or more conditionsfor processing requests sent by the first, second and third computingresource services on behalf of the customer.
 5. The system of claim 3,wherein the second computing resource service comprises an applicationprogramming interface through which customers of a computing resourceservice provider of the first, second and third computing resourceservices are able to send requests to be processed by the first, secondand third computing resource services.
 6. A computer-implemented method,comprising: generating an authentication response by verifying anelectronic signature of a first request, the authentication responseincludes information identifying a set of computing resource services;utilizing the authentication response, based at least in part onfulfilling the first request, to send a second request; processing thesecond request according to a policy determination, the policydetermination is determined by at least evaluating a set of policiesapplicable to the second request based at least in part on theauthentication response; and sending a third request, the third requestbeing processed according to a policy of the policy determination suchthat processing the policy is based at least in part on a user profileassociated with the authentication response that triggered the thirdrequest, including the first request and the second request.
 7. Thecomputer-implemented method of claim 6, wherein: the first, second andthird requests include a cryptographic key; and processing the first,second and third requests involves performance of one or morecryptographic operations using the cryptographic key.
 8. Thecomputer-implemented method of claim 7, wherein the first, second andthird requests include an identifier of the cryptographic key.
 9. Thecomputer-implemented method of claim 6, wherein processing the first,second and third requests is based at least in part on the policy thatcomprises: determining, based at least in part on information providedwith the first, second and third requests, one or more services thateach sent a corresponding request thereby becoming a cause of the first,second and third requests; and determining, based at least in part onthe determined one or more services, that the processing of the first,second and third requests is in compliance with the policy.
 10. Thecomputer-implemented method of claim 9, wherein the information providedwith the first request is encoded in a token generated by anauthentication service.
 11. The computer-implemented method of claim 6,wherein: the first request is triggered by a customer request sent to afirst service, the customer request corresponding to a service provideraccount.
 12. The computer-implemented method of claim 11, wherein thepolicy requires the first request to be sent from a user associated withthe service provider account, and if not, the first request will bedenied.
 13. The computer-implemented method of claim 6, furthercomprising, as a result of sending the first, second and third requests,writing a set of one or more intermediate services that causes thefirst, second and third requests to be identified to an audit log inassociation with the first, second and third requests.
 14. Thecomputer-implemented method of claim 1, wherein: the set of policies areconfigured such that the policy determination is different than thepolicy determination would be if the first request was received from auser of the service provider account compared to if the first requestwas not received from a user of the service provider account.
 15. Thecomputer-implemented method of claim 6, wherein: the policy specifies acryptographic key; and processing the first, second and third requestsbased at least in part on the policy is performed as a result of usingthe cryptographic key required for processing the first, second andthird requests.
 16. The computer-implemented method of claim 6, wherein:the policy specifies a tag value; and processing the first, second andthird requests based at least in part on the policy is performed as aresult of the first, second and third requests being applicable to a setof computing resources associated with the tag value.
 17. Anon-transitory computer-readable storage medium having stored thereoninstructions that, if executed by one or more processors of a computersystem, cause the computer system to: generate an authenticationresponse by verifying an electronic signature of a first request, theauthentication response includes information identifying a set ofcomputing resource services; utilize the authentication response, basedat least in part on fulfilling the first request, to send a secondrequest; process the second request according to a policy determination,the policy determination is determined by at least evaluating a set ofpolicies applicable to the second request based at least in part on theauthentication response; and send a third request, the third requestbeing processed according to a policy of the policy determination suchthat processing the policy is based at least in part on a user profileassociated with the authentication response that triggered the thirdrequest, including the first request and the second request.
 18. Thenon-transitory computer-readable storage medium of claim 17, wherein theinstructions that, if executed by one or more processors of a computersystem, further cause the computer system to analyze a first and secondtoken, generated by an authentication service, provided with the secondand third requests.
 19. The non-transitory computer-readable storagemedium of claim 17, wherein the second request accesses, in plaintextform, data persistently stored in encrypted form.
 20. The non-transitorycomputer-readable storage medium of claim 19, wherein the set ofpolicies applicable to the second request includes at least one policydeterminable based at least in part on the data persistently stored inencrypted form.